Redesigning Redux
medium.com
Redesigning Redux
1–10 of 88 posts
Re: Redesigning Redux
#2This looks nice, although in Redux's favour is a large ecosystem of libraries that will work with it. This highlights a problem I still have with the JS ecosystem, which is relatively tight coupling between libraries. Of course many of these libraries could be glued together manually without too much work, but with the rapidly changing ecosystem and APIs for interoperability between libraries, and the obscurity of some of the libraries (Redux being a good example), this is often just not practical.
Compare this to Elm and the Elm architecture, and it seems worlds apart. Interoperability between libraries that all works in the same straightforward way, checked by the compiler.
It feels like the JS community made a lot of good decisions for the right reasons, but still ended up in a place that isn't great.
Re: Redesigning Redux
#3Rematch reminds me of Marty.js. I like some of the ideas about providing a createStore wrapper that is more zero-config and using something like redux-actions to make reducers simpler. I have been using my own wrapper around sagas to allow for dispatching effects.
They lose me with their idea of "models" where I have a global dispatch that can be extended, like dispatch.modelName.actionName. That's just old school object-oriented thinking layered on top of redux's functional programming ideals.
Re: Redesigning Redux
#4I like it. Configuration should be just that. Interested to read other opinions.
Re: Redesigning Redux
#5This looks nice, although in Redux's favour is a large ecosystem of libraries that will work with it. This highlights a problem I still have with the JS ecosystem, which is relatively tight coupling between libraries. Of course many of these libraries could be glued together manually without too much work, but with the rapidly changing ecosystem and APIs for interoperability between libraries, and the obscurity of so…
Babel is both the driving force of innovation and the cause of much of the fragmentation in JS. Babel allows you to use the latest language features and target the oldest environments. The trouble is that there's not a "right way" to package software to cover all of the deployment concerns. Code needs to work on Node going back several versions as well as browsers going back several versions. And for mobile/desktop websites, your code bundle size is extremely important. Rollup and Webpack 4 go a long way towards making this easier but it's nothing close to a "standard best way" to do it.
Re: Redesigning Redux
#6I've never really understood the point of redux-thunk. But, then, I also don't use asynchronous actions in my datastore.
Asynchronous actions feel, to me, that they belong at the component layer where niceties such as spinners are being rendered, and then the backing store is updated with the results of the triggered action.
What drives people to put all of that into their store?
Re: Redesigning Redux
#7> Consider time_saved to represent the time you may have spent developing your own solution
Developing your own solution is one thing, and developing your own solution that's as battle tested as a popular library is another.
Baking your own solution helps you understand the core problem that a library you could have used tried to solve. But generally speaking developers that tend to do that have difficulty learning top to bottom and favor bottom up approach which leads them to developing things from scratch. That's just a personal anecdote though.
There are cases were a developer has been using a library for a while and is experienced enough to come up with better solution and cleaner APIs but I'd argue that's not the common case.
Understanding other people's code/libraries is a skill worth mastering.
Re: Redesigning Redux
#8Rematch reminds me of Marty.js. I like some of the ideas about providing a createStore wrapper that is more zero-config and using something like redux-actions to make reducers simpler. I have been using my own wrapper around sagas to allow for dispatching effects. They lose me with their idea of "models" where I have a global dispatch that can be extended, like dispatch.modelName.actionName. That's just old school ob…
whats the problem of mixing the good parts of OOP with the good parts of FP?
Re: Redesigning Redux
#9The strength of redux is that all your interactions with it are through functions. Redux today is far better than the Redux of yesteryear thanks to things like ReSelect, Thunks, Sagas, Higher Order Components etc. All these things augment Redux, and they can do so because of Redux's open embrace of the humble pure function.
Once you commit to a config based approach, you're basically closing the door to a future you can't imagine yet. I'm so tired of this short-sighted obsession with configuration some developers seem to have.
I think the author has a myopic vision for where Redux should go.
Re: Redesigning Redux
#10Seems kind of like replacing common functional patterns with esoteric configuration objects?