3 ms·

>I had an impression, that React community (not the authors) considers Redux as an best-practice. A part of React community, yes. Another part, no. Guess which

>I had an impression, that React community (not the authors) considers Redux as an best-practice. A part of React community, yes. Another part, no. Guess which part is vocal because they can write tutorials, examples, articles that generate clicks? ;-) I am as guilty of this as anyone of course, if not the most. Obviously React has some deficiencies addressed by Redux. So does Redux have deficiencies addressed by React. Eventually some of the ideas from Redux might make it back into React. However I suggest learning to build apps with React itself first before using more radical approaches like Redux. You’ll benefit immensely from knowing both ways. I would not necessarily put trust into articles saying “X is the best practice” or “Y is an inferior paradigm”. I would, however, listen to somebody who says “we tried X and Y, and here’s what worked best for us and why”. >My first post was a little bit exaggerated view on where is this whole React-based website developement (including Redux and other libraries and tools) going, not only the React itself. Ah okay, sorry then! These are both interesting, albeit different directions. I think it’s easy to misunderstand them as an “evolution” whereas it’s really a “fork” (in the traditional, non-technical sense). These are two separate ways, and both lead to interesting but different things.

janci 10y ago
I did. I started with React itself. Then I added Redux (first time, it was beacause of the project manager decision). I really like the state reducers. I find internal state clumsy, beacause you have three kinds of functions around the very same state object - get initial state, get state after some props changed and get state after some user action. For simple cases they are very similar to repeatedly write, but still different to abstract out. I hate putting everything in One-Rules-Them-All Redux Store (specially form input on each key press), beacause it creates too much little components to glue it all together - Action declaration, action generator, reducer implementation, projection from Store to component's props I did not see any good solutions that take best of both approaches and I was tired searching. But I plan to wrap my brain around this and think about what exactly is bothering me and how to solve that. In first sight it is what I outlined in my first post. The next thing comes to my mind are Redux-style reducers for component's internal state.
- danabramov 10y ago
  I hope this helps: dispatch(action) { this.setState(prevState => reducer(prevState, action)) }
  - assertchris 10y ago
    Hmmm, that'd be sweet in a mixin... ducks
- mercurial 10y ago
  I never put everything in the one-big-store that rules them all either, but you don't really need to do that. Alternatives: - internal state (sometimes useful, especially for small things that doesn't matter for your underlying data - eg, "is this part of the tree unfolded"). Preferably, with very little logic linked to that state. Note that it can bite you if you use something like redux-undo on your store and your internal state refers to the data controlled by the store. - temporary stores (create a store with a callback function in an event handler, and feed it a callback that invokes an action on your main store) - smaller, specialized stores that get a projection of the data of you main store (this gets a bit awkward with async actions) I'm also trying to avoid fully-controlled text inputs with textareas, I use wrappers with local state which send their content via onBlur().
oldboyFX 10y ago
The majority of developers don't have the time or interest to dig deep into nitty gritties of the React community & ecosystem. They read articles including yours and quickly become indoctrinated into thinking how (for example) putting ALL state into a redux store is a proper way to work with React. This leads to hilarious codebases where people dispatch actions in order to update input values or navigation dropdown open/closed states etc. Trivial apps that could be built over a weekend end up taking weeks to finish. It's a sad reality but most people (including developers) take everything they read at face value and don't devote enough time to critical thinking. We should try to combat this. I'm not saying it's your fault (it's not, you're great), but perhaps you should put a bit more effort into stating how what you're propagating is just one way of writing code and shouldn't be used in all situations (especially simple apps). I've actually seen you do that in a couple of places in the past few months and that's great. I do feel a bit bad about sitting in my chair criticising while you're contributing with all this awesome stuff but you know... with great power comes great responsibility :-)

janci 10y ago

I did. I started with React itself. Then I added Redux (first time, it was beacause of the project manager decision). I really like the state reducers. I find internal state clumsy, beacause you have three kinds of functions around the very same state object - get initial state, get state after some props changed and get state after some user action. For simple cases they are very similar to repeatedly write, but still different to abstract out. I hate putting everything in One-Rules-Them-All Redux Store (specially form input on each key press), beacause it creates too much little components to glue it all together - Action declaration, action generator, reducer implementation, projection from Store to component's props I did not see any good solutions that take best of both approaches and I was tired searching. But I plan to wrap my brain around this and think about what exactly is bothering me and how to solve that. In first sight it is what I outlined in my first post. The next thing comes to my mind are Redux-style reducers for component's internal state.

danabramov 10y ago
I hope this helps: dispatch(action) { this.setState(prevState => reducer(prevState, action)) }
- assertchris 10y ago
  Hmmm, that'd be sweet in a mixin... ducks
mercurial 10y ago
I never put everything in the one-big-store that rules them all either, but you don't really need to do that. Alternatives: - internal state (sometimes useful, especially for small things that doesn't matter for your underlying data - eg, "is this part of the tree unfolded"). Preferably, with very little logic linked to that state. Note that it can bite you if you use something like redux-undo on your store and your internal state refers to the data controlled by the store. - temporary stores (create a store with a callback function in an event handler, and feed it a callback that invokes an action on your main store) - smaller, specialized stores that get a projection of the data of you main store (this gets a bit awkward with async actions) I'm also trying to avoid fully-controlled text inputs with textareas, I use wrappers with local state which send their content via onBlur().

oldboyFX 10y ago

The majority of developers don't have the time or interest to dig deep into nitty gritties of the React community & ecosystem. They read articles including yours and quickly become indoctrinated into thinking how (for example) putting ALL state into a redux store is a proper way to work with React. This leads to hilarious codebases where people dispatch actions in order to update input values or navigation dropdown open/closed states etc. Trivial apps that could be built over a weekend end up taking weeks to finish. It's a sad reality but most people (including developers) take everything they read at face value and don't devote enough time to critical thinking. We should try to combat this. I'm not saying it's your fault (it's not, you're great), but perhaps you should put a bit more effort into stating how what you're propagating is just one way of writing code and shouldn't be used in all situations (especially simple apps). I've actually seen you do that in a couple of places in the past few months and that's great. I do feel a bit bad about sitting in my chair criticising while you're contributing with all this awesome stuff but you know... with great power comes great responsibility :-)