Idiomatic Redux: The Tao of Redux, Part 2 - Practice and Philosophy

[markerikson]

Original author: Rob Wise @rob_wise
Original date: 2017-05-11T05:44:40Z

I've been doing Redux every day in multiple production apps both for clients and for my company's internal project. I have gone through all of the same questions, documentation, and discussions that you have, with the exception of exploring cursors. I have made a lot of mistakes that I had to go back and refactor later after the lesson was learned.

Somehow, I've arrived at exactly the same conclusion as you for every single section in this blog. I'm totally blown away. I agree with 100% of absolutely everything in this article (well okay, I'm a little more biased towards the reducer lookup map syntax than your neutral stance is).

Whether it's the lack of a definitive "right" way to name an action type ("SOMETHING_DONE" or "DO_SOMETHING"), composing reducers within each other and how they don't need to know where in the state tree they are, keeping the different file types in their own folders but sometimes using feature folders within them (I call them "domains"), the downsides of the ducks pattern, choice of async middleware, the elegance of the "boilerplate" that's actually completely necessary, it's all very accurate and great advice. Very well done!

[markerikson]

Original author: Frank Gutierrez @dearfrankg
Original date: 2017-05-11T07:17:30Z

Another great post!

[markerikson]

Original author: Eric(tronica) @ericmasiello
Original date: 2017-05-12T14:37:07Z

Great article! I have (so far) one question. You say: "I would say neither is more "idiomatic" specifically and are perfectly valid choices, but there are some benefits of erring on the side of more logic in reducers."

Can you go deeper on that? Why do you favor putting more of the business logic in a reducer over an action creator?

Here's an example of something I'm thinking about. Pretend I receive some complex, deeply nested data structure from the server but my redux store is really only interested in one piece of it. So imagine i'll need to take this deeply nested structure and filter/reduce/pluck some piece of data from it in order to make the appropriate update to my Redux store. Should that logic for teasing out that data exist in the action creator that simply takes an a parameter the complex data structure? Or should I just take the data structure and pass it along as the payload of my action and let the reducer(s) sort it out?

[markerikson]

Original author: Rhys Powell @rhys_powell
Original date: 2017-05-16T03:22:15Z

It feels to me like pulling data out of an API response is something Redux shouldn't be involved in at all. Typically I'll write my Redux logic to deal with 'normalised' data, and then have some code that sits at API boundaries that can normalise API responses and create valid API requests from normalised data.

Removing API business logic from your Redux stores has a few benefits. One of the big ones I've found is that it allows you to test your logic for parsing API responses and your application's actual business logic in isolation from each other. This means those business logic tests are usually simpler and more expressive, since you don't have to provide a mock API response just to test your Redux store. The other benefit is that it insulates you from changes to the API, as your logic for dealing with that is all bundled up in one part of your codebase.

[markerikson]

Original date: 2017-05-16T03:31:56Z

To some extent, it's about dealing with actions and HMR.

Action creators tend to not get hot reloaded directly. If they do get reloaded, it's usually because they're being imported by a component file, and an edit to an action creator file causes the components to get reloaded via the chain of dependencies.

If you have logic in an action creator that's wrong, and the dispatched action is wrong, you can certainly jump back to before that action, edit the action creator, cause it to get reloaded, and try again. On the other hand, if you have logic in a reducer that's wrong, it might be a bit simpler and faster to iterate on the process of getting the reducer right, because the action itself is correct - it's just a matter of getting the reducer logic right.

So, again, no hard and fast rules here, but the process of iterating on reducer logic _might_ be faster.

For your example, I can see it working either way. I personally prefer to have relatively minimal-sized actions, so I'd actually go more towards dealing with the complex structure on the action creator side of things.

[markerikson]

Original date: 2017-05-16T03:32:48Z

Yeah, a lot of the API-related logic could definitely be independent of Redux. Even if you're using a Redux middleware to handle the calls, the actual processing logic could probably be separated out.

[markerikson]

Original author: Carl-Erik Kopseng @carlerikkopseng
Original date: 2017-06-01T19:39:32Z

Great article that expanded on many of my weak points in understanding the hows and whys.

[markerikson]

Original author: Andy Gimblett @andy_gimblett
Original date: 2019-09-27T09:24:43Z

Lovely stuff - so many thanks for this (and the whole series); as someone early on in the react/redux journey this is a real gem. One heads up: your Chesterton's Fence link is dead. Thanks!

[markerikson]

Original date: 2019-09-27T23:39:51Z

Thanks for the comment, and for pointing out the dead link! Just fixed it by pointing to an archive.org cache link.

We're planning to revamp the Redux core docs in the near future, and I hope to include some of this material in a "Thinking in Redux" section in the docs.

[markerikson]

Original author: Jenkins
Original date: 2019-11-21T14:38:50Z

Hi, thanks for the great article, it made things much clearer for me!

However, I have to iterate the thing with the switch statement once more, because I think I'm still missing a point here. As somebody who is new to flux/redux, I think I can tell you why people are (or at least I am) so unconfortable with it: all my life I've learned, that seperate concerns go into seperate functions. And then we go ahead and pack the logic for totally different actions into one dispatcher function. And I think I still don't understand why we do this, or what are the benefits of that. Would it not be possible to, instead of passing an action-object with a type field, pass an action-function that we can call directly? Like so:


const anActionType = (payload) => (state) => {
// do something
return newState;
}

function dispatch(state, action) {
action(state);
}

dispatch(anActionType(myPayload))


What am I missing here? Would that approach have any significant disadvantages? Thanks!

[markerikson]

Original date: 2019-11-24T17:56:39Z

A couple different thoughts.

First, remember that a Redux app only has one reducer function in the end: the "root reducer" you passed to `createStore`. But, we split that function up for maintainability, and the preferred method for splitting that logic is based on "slices" of state, so you end up with a `usersReducer` managing users, etc.

That right there _is_ splitting up "separate concerns into separate functions".

From there, that slice reducer's job is to update the slice of state that it owns. _Any_ action that could affect that state _is_ its concern. Handling different actions is not "separate concerns". And, per the article, most of the logic is entirely based on what the value of `action.type` is, it needs a quick way to check that value.
So, it's entirely reasonable to use a switch statement there.

And no, that approach is incorrect for Redux, because actions are supposed to be plain serializable objects, and putting functions in them makes them non-serializable and non-traceable. The approach you're showing is what I referred to in this post as "putting reducers in actions".

Hopefully that helps clear things up.

[markerikson]

Original author: Jenkins
Original date: 2019-11-25T13:22:13Z

Ok, so having actions as objects is actually the point, s.t. they are serializable - I guess for debugging purposes mainly. I think I got it, thanks!

[markerikson]

Original author: mani
Original date: 2020-07-08T16:04:01Z

Roku is one of the most famous live streaming TV in the United States. The organization is providing a broad array of products like Roku TV, Roku Ultra, Roku Premiere, Roku Streaming Stick, and many more. Roku products are recognized for their simplicity but sometimes users encounter Roku Activation problems and it seems very challenging for them. Today here in this post, we are going to discuss Roku Enter Com Link. Roku devices can offer its users with the best way to stream their show on TV. Nowadays, streaming players are more focused on offering the best and easy method to stream shows and programs. Also, Netflix, HotStar, Amazon Prime Video, YouTube, or any other streaming, Roku streaming device will enable you to enjoy each one of them.
Roku Enter Com Link Setup
Roku Enter Com Link is applied to activate Roku Streaming Player or Device. To enjoy all preferred channels, programs, videos, shows, and many more, users are required to activate the Roku Activation Code with a Roku Account. After buying the Roku device, you are required to create a Roku enter com link account for a streaming device with outstanding media programs or add new free or pro channels on your Roku streaming device. Roku has approx 3500+ channels and shows.

[markerikson]

Original author: Rob L. @roblifford
Original date: 2020-08-09T23:34:57Z

FYI, the link with text "Redux FAQ question on async logic" is 404 now. That may want to go to a subsection of https://redux.js.org/faq/ac... now.