11–20 of 74 posts
At work I've started keeping the reducer in the actions file, anyone else do that? This way they can share the same const declarations, and you don't have to toggle between two files when most actions / reducers are pretty small.
At work I've started keeping the reducer in the actions file, anyone else do that? This way they can share the same const declarations, and you don't have to toggle between two files when most actions / reducers are pretty small.
I originally tried this but then discovered combineReducers() this will allow you to organise your reducers into a single import. I found it a more sane way to organise all of my reducers, as the majority of them were small. Here's a link for API http://redux.js.org/docs/api/combineReducers.html
In this tutorial, the author makes the call directly in an action, which is not its responsibility. Here's an example of the "api" middleware we've developed (https://gist.github.com/tomazzaman/a98f5ad3f052592e564862e4d...), and the beautiful part is, this is the only file in which async calls are made. And it's a rather small file, which allows me to change to any ajax library (like the native fetch when it gets more support) I want at any time, with very little development.
Bottom line: middleware is awesome, give it a try. :)
For example, say I have a page with reviews on it. So there's a Component that handles editing a review. Where does the state for all the form inputs go? Does it go in the Redux store? If it does, then every time the user types a letter you get an event, which goes walking backward through the component tree until it hits the review editor Controller, which generates an action, which dispatches to the store, which gets reduced causing a state change, which then percolates back up through the Controller/Component tree to finally add that letter to the input. That walking back and forth is bad enough on its own, let alone generating an entirely new state (because the state is immutable) for every single letter the user types. It's inefficient, and it adds noise into the action log.
The alternatives seem to be storing the state in the component in which the typing is happening, or in the parent Controller, and then only generating update actions against the store when some "finished typing" event occurs (i.e. onBlur or timeout). Of course this seems to go against the idealistic implementation of Redux where all the state is stored in that one state object and it's immutable.
My point being, I haven't stumble across a "real world" tutorial that goes over this stuff. I wouldn't quibble about that normally, as I'm happy to play around and find the solution on my own, but this feels like such a common and important task (what website doesn't have forms of some kind?) and the performance and maintenance implications of how this is implemented seem large. So it would be nice if there was a "We built this huge web app using React and Redux, this is how we ended up doing forms and it works well for us" article.
There seems to be a big blind spot in these Real World React+Redux tutorials when it comes to forms. For example, say I have a page with reviews on it. So there's a Component that handles editing a review. Where does the state for all the form inputs go? Does it go in the Redux store? If it does, then every time the user types a letter you get an event, which goes walking backward through the component tree until it…
> let alone generating an entirely new state (because the state is immutable)
Assuming you're talking about the redux state, this is only if the state changes. Dispatching an action to change the state of your form should cause the form's entire state tree to change at most, and possibly as few as one or zero objects. All those other redux reducers that just return the previous state are not going to have any performance impact.
In effect, your state is immutable but you're only getting "new" state references for a small portion of the state atom, very cheaply.
There seems to be a big blind spot in these Real World React+Redux tutorials when it comes to forms. For example, say I have a page with reviews on it. So there's a Component that handles editing a review. Where does the state for all the form inputs go? Does it go in the Redux store? If it does, then every time the user types a letter you get an event, which goes walking backward through the component tree until it…
There seems to be a big blind spot in these Real World React+Redux tutorials when it comes to forms. For example, say I have a page with reviews on it. So there's a Component that handles editing a review. Where does the state for all the form inputs go? Does it go in the Redux store? If it does, then every time the user types a letter you get an event, which goes walking backward through the component tree until it…
[1] http://blog.workshape.io/the-3ree-stack-react-redux-rethinkd...
There seems to be a big blind spot in these Real World React+Redux tutorials when it comes to forms. For example, say I have a page with reviews on it. So there's a Component that handles editing a review. Where does the state for all the form inputs go? Does it go in the Redux store? If it does, then every time the user types a letter you get an event, which goes walking backward through the component tree until it…
It basically works as per your first guess: Everything goes in the store. And no, it doesn't really have any performance or efficiency issues. Try it out and see. :)
At work I've started keeping the reducer in the actions file, anyone else do that? This way they can share the same const declarations, and you don't have to toggle between two files when most actions / reducers are pretty small.
This allows you to encapsulate all of your Redux actions/reducers/etc into standalone "providers". It decouples pretty much all of your React components (UI) from your Redux logic (models/controllers), which maximually separates your concerns and makes it trivial to reuse anything anywhere. It also allows you to instantly swap databases and/or websocket implementations.