Nice. I've thought of some of these myself and implemented them as helper functions, but there are some new ideas here I hadn't thought of. Not sure I'm ready to port my project to a new library, but I may try some of these out piecemeal.
Redesigning Redux
11–20 of 88 posts
Re: Redesigning Redux
#12> 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 t…
As far as libraries generally go, Redux is tiny.
https://github.com/reactjs/redux/tree/master/src
The largest and most important part is CreateStore, but at 250 lines long (mainly comments), it's shockingly simple when you take a look at it.
Re: Redesigning Redux
#13I'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?
The beauty of Redux and react is that you can do that and nobody's going to tell you you're bad for doing it.
Even Dan Abramov did it in his recent Redux presentation.
It's important that we understand why "best practices" exist but to never see them as commandments. Do what makes sense for your case, but it's your own funeral if you're deviating from best practices without having fully thought it through first.
Re: Redesigning Redux
#14I'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?
Part of the idea behind Redux is to keep components as pure as possible and limit side effects to one place, usually actions. You keep all async actions in components?
Re: Redesigning Redux
#15I'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?
The beauty of Redux and react is that you can do that and nobody's going to tell you you're bad for doing it. Even Dan Abramov did it in his recent Redux presentation. It's important that we understand why "best practices" exist but to never see them as commandments. Do what makes sense for your case, but it's your own funeral if you're deviating from best practices without having fully thought it through first.
I'm not saying anyone is "bad", I'm saying that I don't see why it makes sense to include the responsibility of acquiring data into the thing that stores data.
Re: Redesigning Redux
#16This 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 w…
That's a good summary of the fragmentation and coupling in the build tools, but there's also the libraries themselves - React, Redux, React-Router, React-Router-Redux, etc etc.
Re: Redesigning Redux
#17> 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 t…
I'm afraid I'm guilty of this type of re-invention myself. Having built a very large project using Redux, I decided to develop my own alternative, not just to Redux, but to Flux itself:
https://hackernoon.com/transmission-tx-a-flux-alternative-fe...
I'm convinced it's better and simpler, but then again, I'm arguably biased.
Re: Redesigning Redux
#18This approach looks really similar to the VueX approach: synchronous reducers are mutations, and async effects are actions. Can't wait to try this out in my next React project.
Re: Redesigning Redux
#19> 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 t…
> 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.
Damn, that was a hard pill for me to swallow just now.
Re: Redesigning Redux
#20I'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?
The problem with putting all async code directly into components is that often, async code is business logic or some other non-view-layer thing that doesn't really belong in a component.
The benefit of redux-thunk (and there are obviously other alternatives that provide the same value) is that it lets you write plain functions that have nothing to do with the store, and nothing to do with components. If you put all your business logic into these plain functions, then they're really easy to test, reason about, move, refactor, etc.
> What drives people to put all of that into their store?
It's worth pointing out that redux-thunk doesn't move async code into your store. The store (i.e. reducers) is still completely synchronous.