Redux-toolkit: Does useSlice encourage people to "Think in Redux" correctly?

[fdjones]

Firstly, thank you for RTK, I've been using it for a while now and I love it :)

My concern is potentially with the createSlice function, which I've been using and initially really liked. I recently watched a talk which spoke about Redux as basically a pub/sub model, which made sense to me. In that case, coupling your actions to your reducers seems like an anti-pattern, because rather than dispatching actions that represent business events, you're potentially dispatching multiple actions. I know you _could_ get around this by simply having the slice reducer listen for any action you want, but it feels like maybe this doesn't encourage people to think in Redux the right way (if, indeed, a pub/sub model is the right way to think about it?). Perhaps you don't agree that this is the right way to think about Redux and if not I'm happy to be corrected.

Anyway I'd be interested to know your thoughts on this, and again thank you for this and the other awesome libs you guys maintain :)

Also, here's a link to the talk if you'd like to hear this idea explained far better than I have: https://www.youtube.com/watch?v=K6OlKeQRCzo

[phryneas]

Hey there!
You're absolutely right with this pub/sub interpretation, and in fact the new Redux Style guide contains points like model actions as events, not setters and allow many reducers to respond to the same action.

But at the same time, there is a question of practicality.

Take a look at these scenarios:

1. Many actions are dispatched to trigger many changes in one or multiple reducers.
2. One action is dispatched to trigger one or many changes in one reducer.
3. One action is dispatched to trigger one or many changes in multiple reducers.

Taking a look at those three scenarios, 1. is clearly the antipattern you are referring to. Going by write meaningful action names (and "model as events"), you will quickly arrive from 1. to 2., combining the effects of multiple setters into one reaction to a meaningful event. And this is where slices really shine. Also, I'd wager that 90% of actions happening in a web application only have effects in one part of the store, so you would see slices as a great way of handling these 90% of interactions.

Going forward from there, things get a little less straigtforward when you start treading into 3. territory. Here you'll have to distinguish: is there still a slice that is most closely related to an event? Then in my opinion, it's still fine to have that action-event as part of the slice and make other slices react to that primary slice's action-event.
There might be some actions that live without such a primary slice - and then it would be time to move that action out of the slice it was in (just keep it as createAction somewhere) and have all slices just react to that one event.

And going even further, you might have one of those rare applications where there are just action-events of type 3 - and in that case, I'd move away from slices and just have actions and reducers.

So in the end I'd say that slices neither encourage nor discourage your antipattern itself. They simply are an abstraction that works very well in many cases and reduces boilerplate a lot for many people. And this is something the community has been craving for and splitting up the ecosystem (here's a list of a few hundres redux helper libraries all trying to cut down boilerplate).
We're just trying to reduce this fragmentation by providing something that works most of the time (but not always) as part of an official tool.

But in the end, it's perfectly fine and depending on your use case whether you choose to use them :)

[fdjones]

Hi, thank you for the detailed reply it makes a lot of sense. As you said it's probably best to do it on a case by case basis, and if nothing else then createSlice makes it easier for teams to refactor without having to re-architect their entire application -something we're doing with createSlice right now =). I think if I was starting a greenfield project I'd probably try and go for number 3, but that likely wont' be for a while!

Thanks again - would you like me to close the issue?

[phryneas]

Just wanted to await your answer to see if there was more need for discussion - I'll close this one then :)

Have a nice day!

[markerikson]

Just want to say that I completely agree with everything @phryneas said, particularly the "90% of actions are only handled by one reducer" part.

Really, the most important aspect of createSlice is that it auto-generates action creators and action types without you having to explicitly write them by hand. They still exist, but you no longer need to take the time to think about them - they're now a background detail.