Seeking Feedback on Effect/React State Management Pattern Transition
Could I get some thoughts/opinions on this effect/react state management pattern?
https://gist.github.com/riordanpawley/28bbfd4b22f332d4d34c0cd1d5d1bd32
We are currently using a reducer based solution to accomplish basically the same function.
The reason we went with a fluxxy style of state management is we have quite a few super complex screens/features that were super hard to get right without the structure flux arch provides.
The problems I am trying to overcome with new pubsub pattern are:
1. I was trying to avoid the plain, json serializable, object requirement in state and events that redux has by making use of Schema encoding/Schema.parseJson. This meant I had to Schema.Union every single event in my app in order to encode them for sending to dev tools. I believe this giant union and the smaller "slice" unions were largely to blame for the slow lsp perf in our store package because as I understand it: typescript doesn't love unions.
2. My team struggled with the bad DX of events not living next to their handlers. They wanted to be able to "go to definition" on an event that they saw dispatched in react and be able to instantly see what happens next (of course if the event is cross cutting this current solution doesn't solve that problem but most events don't cross cut).
3. My team struggled with the sheer size of some of our reducers. We have reducers that are 2k lines long. I know there are ways to mitigate such as pulling the handler logic into functions ( which we did) but I don't love this approach.
I'm going to run some tests to figure out if this approach will work for us but I would love to hear any thoughts too
https://gist.github.com/riordanpawley/28bbfd4b22f332d4d34c0cd1d5d1bd32
We are currently using a reducer based solution to accomplish basically the same function.
The reason we went with a fluxxy style of state management is we have quite a few super complex screens/features that were super hard to get right without the structure flux arch provides.
The problems I am trying to overcome with new pubsub pattern are:
1. I was trying to avoid the plain, json serializable, object requirement in state and events that redux has by making use of Schema encoding/Schema.parseJson. This meant I had to Schema.Union every single event in my app in order to encode them for sending to dev tools. I believe this giant union and the smaller "slice" unions were largely to blame for the slow lsp perf in our store package because as I understand it: typescript doesn't love unions.
2. My team struggled with the bad DX of events not living next to their handlers. They wanted to be able to "go to definition" on an event that they saw dispatched in react and be able to instantly see what happens next (of course if the event is cross cutting this current solution doesn't solve that problem but most events don't cross cut).
3. My team struggled with the sheer size of some of our reducers. We have reducers that are 2k lines long. I know there are ways to mitigate such as pulling the handler logic into functions ( which we did) but I don't love this approach.
I'm going to run some tests to figure out if this approach will work for us but I would love to hear any thoughts too
Similar Threads
Was this page helpful?
