-
-
Notifications
You must be signed in to change notification settings - Fork 85
Global reducers do not work in TypeScript 4. #174
Comments
This is accurate. I am not aware of a solution. The reducers do circularly reference themselves, so TypeScript is not wrong to say that; but I feel it is wrong to fail to compile, since it worked in earlier versions and works at runtime. In the meantime, you should be able to migrate your global reducers from |
I'm not sure what you mean by this, can you clarify? |
Right now you are using
This would be how you can refactor it to be defined locally instead of on the global ReactN object:
You can also replace this with a property reducer to simplify it further:
The idea is to get rid of |
@CharlesStover The approach you described here is totally legit, and I am using it successfully even with Server Side Rendering, thanks.
|
The global reducer idea would have actually been very appropriate in this context. Have a global reducer sat in front of all the global state to make it clear that no global state should be updated directly. As it stands there is a referencial cycle which can't be avoided when using typescripts `addReducer` function which reactn uses for it's own `addReducer`: CharlesStover/reactn#174 Charles's own advice is to use local reducers instead. I still want to get some kind of benefit like that described above, and while I don't think it's actually as semantically clear doing it locally like this there probably is scope to have saga's like reducers like the one I've created here at `setNewHarpStrataReducer`. Making this pattern ubiquitous in the way required though would be out of scope for this feature. I'll have to raise it as techdebt.
Type inference for reducers appears to be broken with TypeScript v4 and reactn 2.2.7.
For some reason, useDispatch(reducerName) results in the following error:
// ERROR: Type of property 'increment' circularly references itself in mapped type 'DispatcherMap<State, Reducers>'.ts(2615)
Below is an example.
Here is a second, related issue. The types for Provider.useDispatch does not accept strings even though the global version does.
The text was updated successfully, but these errors were encountered: