Hypothetical wishlist ideas

[markerikson]

Opening this up for random ideas that we could at least consider adding to RTK or the Redux ecosystem someday. I'm creating this as a discussion rather than an issue because A) better threading, and B) won't annoy me if this never gets closed

Starting off, from a Reddit thread I bookmarked a couple years ago:

Of applications that do need redux, he's completely on the money about them getting progressively more complicated as redux is leveraged for prop drilling more than global state management.

One of the things I'm still astonished by with redux is the lack analysis tools that can examine your state management, generate a report, and show you all of the dark crevices a state property winds up and how many side effects a single action can have.

As far as I've been able to tell there isn't a documentation tool that shows where an action can get fired from. What middleware is attending to it (and what actions it fires off as a result), and finally what reducer listens to it.

Showing how data is changed would be awesome (but not really practical).. however just showing all of the places an action has side-effects against in a flow chart or process diagram would be a big win for just touching an enterprise redux code base without breaking gobs of stuff as a result because of lack of awareness.

Redux dev tools doesn't seem like it's really met that requirement yet... and waiting until the action actually runs doesn't make for good static documentation. I figure something like this could inspect reducers and middleware during unit tests and generate a report after the unit tests execute...

might also be useful for determining coverage for all of your known actions (assuming you have some defined list of action types).

[nathggns]

Something to do with data driven side effects - I.e, when the state matches X condition (probably driven by a selector), do Y, until it no longer matches that condition, in which case it's cancelled. Think for example, a music player where there is a selector that indicates if it should be playing or not. We can drive this by actions with things like thunk/sagas, but definitely becomes difficult if there's a million different actions that can change this state.

[markerikson]

My first response is that sounds like your best bet is mashing together XState and Redux, by using an XState machine as a Redux reducer and hooking the service up as a middleware per this example:

https://github.com/mattpocock/redux-xstate-poc

[Faithfinder]

Well, personally I think one of the worst parts of redux experience is action dispatching. I understand that it's largely what makes defines redux, and I know that a hook analog to mapDispatchToProps was thought about and discarded, but I still believe that this part could have better DX. Somehow. (no specific ideas, sorry)

[Faithfinder]

@Faithfinder I guess I'm still not quite clear on what specific problem you're pointing to here. Is it that Redux requires you to dispatch() something in order to do anything at all, or the fact that you have to explicitly reference the dispatch() function in your own code?

Aren't those the same problem? Or can you do redux without dispatching? But yes, I mean explicit referencing in my own code.

[markerikson]

No, those are two different things: the need to dispatch() to make something happen, vs whether the actual function name dispatch shows up in the code that you write.

Redux requires dispatching. Period. That is how the Flux Architecture works. Literally the only way to trigger update an update to the store is to dispatch an action object. Since thunks are a way to write code that will interact with the store, without knowing ahead of time which store they talk to, they also require passing the thunk function to dispatch. So, all that behavior is non-negotiable, because without it it's no longer Redux.

The question of whether you yourself literally have to write dispatch() in your code is different. connect() intentionally abstracted that, so that your wrapped component would be able to call props.increment() and have that be a pre-bound action creator that calls dispatch() internally, without your own component needing to "know" that it was actually dispatching.

Now, that wasn't strictly necessary. After all, if you didn't provide a mapDispatch argument, your component automatically got this.props.dispatch instead, and you could always do this.props.dispatch(increment()) in the same way we now do it with useDispatch(). But, our encouraged pattern at the time was to use mapDispatch so that the whole "container/presentational" thing was used and the wrapped component was, in theory, more reusable and testable.

With hooks, that calculus changes. As I described in my post Thoughts on React Hooks, Redux, and Separation of Concerns and my talk ReactBoston 2019: Hooks, HOCs, and Tradeoffs, hooks change the way we write components so that they are now responsible for dealing with their own data dependencies. That includes Redux.

So, between the technical problems of potential name clashes with a useActions hook, the removal of the need to pass bound action creators as props, and a desire to remove a layer of abstraction that is no longer necessary and often confused people, we settled on just providing useDispatch() and telling users "write your own click handlers that call dispatch() when you need to".

Yeah, it's a couple more lines of code. Like anything else, you can write your own abstractions for this if you really want to.

But at this point it's not a problem that needs to be solved further.

[mikoz93]

Like anything else, you can write your own abstractions for this if you really want to.

Isn't the whole reason behind RTK is to simplify already existing solutions and take away the need for people to make their own abstractions? I think what's being suggested here is to go a step further with the current abstractions provided by RTK, such as createAction and wrap the dispatch in whatever is being returned. Consumers don't really care what it does under the hood as long as it provides the same interface (minus the manual dispatch of course).

[markerikson]

I'm saying that A) I don't think this is a problem that needs to be solved, B) it's not a problem that I want to try to address given the previous discussions during the hooks alpha development.

To be clear, this is really a React-Redux-ish question. Yes, we do have some React-based APIs included in RTK now that we have RTK Query, but there's nothing about the existing RTK APIs that would be relevant here. The only vaguely viable technical option that matches what I think you folks are describing is the useActions() hook that we already discarded during the hooks alpha. That would be more of a React-Redux thing than an RTK thing, but I truly don't see that as a pain point that's worth adding a new API for.

[phryneas]

I'll add to this:

dispatch has to come from somewhere.

We cannot do that with a fixed store binding during the createSlice call, since at that point no store exists yet. Also, we would not do it there, since a fixed binding at that point would greatly hinder many types of unit and integration tests that rely on the existance of multiple stores.

We could provide useActions(), but that hook has been a copy-paste solution as part of the Redux hooks, (if you wanted to, you could already be using it for years) and it has the problems Mark already added.
If you were to use that, it would look like

const { increment, decrement } = useActions(counterActions)

At that point it is incredibly difficult to explain to a learner why they could not just call counterActions.increment() instead. Even worse, you get shadowing if you do not do a import * as counterActions from './counterSlice', but import them manually. Also, it gets even more error-prone that way. Is increment already bound or not? That's confusing.
And we want people to import individual actions. Because that works well with IDE autocomplete. They don't even need to know which file it comes from (and going by handle actions as events, not setters, they should not care what file it comes from - they are dispatching an action that could be handled in 20 different reducers at that point), they just write increm and hit ctrl + space.

Then there would be that last solution of creating one hook per action creator. But does that really save any code?

const increment = useIncrementAction()
const decrement = useDecrementAction()

return <><button onClick={increment}>+</button><button onClick={decrement}>-</button></>

vs

const dispatch = useDispatch()

return <><button onClick={() =>dispatch(increment)}>+</button><button onClick={() => dispatch(decrement)}>-</button></>

This approach in my eyes does not save any code. It just adds magic and hides intent.

[MikelArnaiz]

I'd like to see built in code splitting support in RTK. And I'd love to know your opinion of how this should look like.
I know about the The problem of code splitting (mainly SSR) but there are some options out there, like the suggestions from the docs or the reducer registry.

Regarding libraries offering just that (redux-dynostore, redux-injectors, redux-dynamic-modules) they are all, unfortunately, deprecated or semiabandoned.

An out of the box solutions will probably encourage its use.

[markerikson]

Yeah, the most recent one that popped up just a few days ago is https://github.com/fostyfost/redux-eggs .

I think this is a use case we could potentially try to address, but I'd say this is a lower priority on our end atm.