CODEWITHSUNDEEP
reactjsreduxreact-redux
ssuhat
ssuhat

Reputation: 7656

React Redux Why most guideline separate every types?

I'm curious why most guidelines of separate every types?

for example:

 //List of Posts
FETCH_POSTS: 'fetch_posts',
FETCH_POSTS_SUCCESS: 'fetch_posts_success',
FETCH_POSTS_ERROR: 'fetch_posts_failure',

// Single POST
FETCH_POST: 'fetch_post',
FETCH_POST_SUCCESS: 'fetch_post_success',
FETCH_POST_ERROR: 'fetch_post_failure',

I've got the idea within success and error got separated. But for fetch_posts and fetch_post that only has one job to trigger ex: isLoading why it must got separate? why not make one type for ex: FETCHING?

Thanks

Upvotes: 0

Views: 49

Answers (1)

Kirill Shumilov
Kirill Shumilov

Reputation: 307

I think the answer that actions is not what you want to do — it's what already happened (according to Dan Abramov). So there is no place to "*ing": FETCH_POST may be named as FETCH_POST_REQUEST (user just requested posts), and succedeed or failed then.

I asked the same question in the past and somewhere found the answer that this is only one of the implementations. It has its pros and cons, but in fact, the standard FSA contains an object with meta-data that may contain statuses (request / success / failure and maybe some more).

Some advantages of the solution with different action types:

  • a simple switch in the reducer;
  • a simple usage of redux-saga (takeEvery('FETCH_POST') is easier than takeEvery and filter by some props);
  • it have clear names (for example, it's easier to debug in redux-devtools when you just looking at list of dispatched actions);

But another approach has advantages too:

  • You can easily handle any async processes in a reducer for any action (if you're just looking for action.meta.status, for example). But it has a fairly narrow field of application, for example, a single progress bar for all asynchronous tasks.
  • less action types;

I believe that both have a right to life, but you should clearly understand what benefits it will bring to your application, and which one will be easier to maintain.

Of course, nothing prevents you from mixing these approaches, but this may cause errors and difficulties in the support, so be careful.

Upvotes: 2

Related Questions