I think redux is a great pattern for state management. With that said, I think there is still room for improvement.
Like most people have mentioned, it would be nice if we could some how reduce the amount of boiler plate needed, or perhaps a pattern will emerge that will help manage it better.
For me, the true benefits of redux became clear when I learned how to properly normalize the shape of the data (https://redux.js.org/recipes/structuring-reducers/normalizin...) in the store. Unfortunately to do this efficiently it requires more boilerplate and dependencies like normalizr.
At this point in the evolution of SPA architecture, it definitely feels like something is wrong because of the way we manage our data across the stack. We normalize our data to our RDS, de-normalize it in our API, then re-normalize it in our application interface.
Interesting and exciting to watch the evolution take place though.
Hah, I wrote that whole "Structuring Reducers" docs section! Glad it was beneficial :)
I personally am a fan of Redux-ORM [0] as a tool for handling normalized state in the store (and I show how to use it in my "Practical Redux" tutorial series [1]), but there's quite a few other options as well.
My biggest frustration with the word "boilerplate" is that it not only gets thrown around a lot, it means different things to different people. Which _specific_ aspects concern you? What pain points have you experienced?
It's well written, so thanks for that. I have a client project coming down the pipe that will likely include redux, so I'll have to check out Redux-ORM.
I agree that the term boilerplate has been diluted lately. I also have to admit that I use it in this instance because it seems to have become the adopted term for what essentially means "takes a lot of code no matter the complexity". So to clarify, when working with Redux, it _feels_ like it takes a lot of code to handle data in states, no matter the complexity.
More likely, redux is intended for larger projects with complex state management. So yeah, there is a lot of code to setup even basic data within a state, but the benefits probably start paying dividends as the state becomes more complex. With that said, I doubt anyone working with extremely complex states is complaining about too much "boilerplate".
I was considering contributing to Redux but when I checked github it didn't seem like there was too much that needed help. Let me know if that's not the case. I love the project and would enjoy contributing.
The part about normalized data being (re)transformed across the stack is so true. I don't know what the answer is but it's really funny how we are doing that. GraphQL does seem to help but I don't think it's a silver bullet
Like most people have mentioned, it would be nice if we could some how reduce the amount of boiler plate needed, or perhaps a pattern will emerge that will help manage it better.
For me, the true benefits of redux became clear when I learned how to properly normalize the shape of the data (https://redux.js.org/recipes/structuring-reducers/normalizin...) in the store. Unfortunately to do this efficiently it requires more boilerplate and dependencies like normalizr.
At this point in the evolution of SPA architecture, it definitely feels like something is wrong because of the way we manage our data across the stack. We normalize our data to our RDS, de-normalize it in our API, then re-normalize it in our application interface.
Interesting and exciting to watch the evolution take place though.