Business logic belongs in action-creators. I think this one is very important although it may not be immediately obvious. Do more in action-creators and less in reducers This reduces the likelihood of mistyped variables that lead to subtle undefined values, it simplifies changes to the structure of your store, etc. prefer myValueSelector(state) over state.myValue). So my first recommendation is- use shared selectors everywhere- even when synchronously accessing data (eg. We also use them in thunks returned by action-creators (more below). For example, we use them in automated tests. Over time we've realized that there is added benefit to using these same selectors in other places (not just in the context of reselect). Our "smart" containers then use those selectors to parameterize our "dumb" components. We typically define a file that exports selectors for a given node of our state tree (eg. This first one is not strictly related to Redux but I'll share it anyway since it's indirectly mentioned below. (Or perhaps I've just missed where it's covered, in which case I apologize.) But as I've written more code and more tests I've come to have stronger opinions about where things should be and I thought it would be worth sharing and discussing with others. The documentation seems a bit vague on this fact. Along the way I've occasionally found myself thinking about a feature and wondering "does this belong in an action-creator or a reducer?". My team has been using Redux for a couple of months now.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |