Find me on medium.
When you're building out a react application, small projects can often be a little more flexible than large projects when it co...
For further actions, you may consider blocking this person and/or reporting abuse
In addition to tests I'd also recommend TrackJS, because it catches errors encountered in the wild.
Another thing that I've noticed people to do is to rename a thing, super minimal example:
I think the worst I've had to refactor had three or four different names, while not being the only thing changing it's name as data was passed on.
A third point I've noticed in larger apps is that people seem to develop their own solution each time they can't find something using keywords that pop into their mind. This is one of the reasons naming is important to spend time on. However this is also a communication issue.
Those points are right on! Miscommunication should have made it into this list. Miscommunication causes duplicate component implementations because it wasn't visible to the developer at the time. After the issue occurs sometimes we won't have enough time to merge them together because we're being pressured to finish another thing within the end of the day. This causes two separate implementations that practically do the same thing except a tiny change somewhere, like a different named prop for example.
Those of you reading this please make a mental note that communication with your teammates saves time and progress.
IMO another thing that's easy to do "wrong" is to abandon a core idea of Redux / Elm -- that your app has a single set of named behaviors drawn from a "menu" of action constants. In Elm, you're basically forced to stick to that architecture, but in Redux, the side effect libraries offer various escape hatches.
Once you drop in
redux-thunk, you get another place to stick app logic. That logic can be composed of multiple actions firing, with time-dependent (can't think of a better way to say it) data being passed between them.With
redux-saga, since the sagas are long-running, values living in the generators can act as implicit app state.The closest thing to Elm's ideal that enables side effects is
redux-loop. While it may not be the best choice for every app, IMO it's generally good to be cautious around things like: logic moving out of named actions, unnamed "meta-actions," and app state that lives outside of the store.I'd argue that things like which files code lives in, or what variables get named, while good to get right, are less costly to fix than runtime behavior that works but is hard to reason about. Which is something that the combo of discrete, named actions & immutable state is meant to avoid.
Not sure why they're called accessor functions, the common name for them is selectors. The benefit of using selectors is that you can make selecting slices of state a lot easier. They are also composable for cases where you want to use multiple selectors to select multiple slices of state and combine, transform or filter them (e.g. for relational data).
Another benefit is that selectors can be memoized. Since they are (and should be) pure functions they'll always produce the same output from the same input. For example, if you have a selector that does a lot of work (mapping, filtering, reducing, etc.) and it is called often, memoization can be useful to avoid performing the slow operations each time for the same inputs.
These practices and benefits doesn't only apply to selectors but also React components themselves!
I highly recommend reading about this within the reduxjs/reselect GitHub repository.
Your welcome!
I think there are couple of reasons for choosing mapStateToProps over the useSelector in some conditions. Yes, Hooks like useSelector is powerful and it does have some benefits like memorization ,and using reselector can also avoid ‘accessory function’; however, if the component needs to touch base with lots of values in the state or more nested structure by the components. mapStateToProps in a separated file is much more organized and easier to maintain, because it will isolate the JSX components as UI as possible and also let test easier. It’s also depended on how the project structure is desgined at the first. If the components have a few state values should talk to or values are bond to components, which means they are cohesive, using useSelector is a good idea. It will drop some unneeded code. Nevertheless, we shouldn’t overuse the useSelector, for example adding tons of selectors in the component and make file gigantic or using same selector in multiple components.
Thanks for the article. I'm wondering what is the third argument inner function of Redux Thunk receives that you are destructing as
{ api }on src/actions/sorceress/equipping example?yep, useSelector hook is much better than obsolete mapStateToProps
Can you elaborate more why ducks-modular-redux pattern is bad?