3 ms·

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

by 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().

by janci 10y ago

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().