Redux is based on other technologies like Flux and Immutable.js that are based on the principles of immutable data structures, a single source of truth, and the use of pure functions for state updates.
Immutable data structures already exist in JS, all of our primitive data types are immutable (numbers, strings, etc.). This means we cannot intrinsically change this value, only replace it with a new one. Complex application data however is often best stored in more flexible structures like an object or array, which are both mutable (can be changed in place).
Having a single source of truth means centralizing where you communicate updates to your data as well as where you get it from. Even trivial applications with different stateful parts can get difficult, imagine the additional struggles when you throw in asynchronicity and the reality that things don’t always work into the mix.
Pure functions always return the same output for a given input. These functions don’t rely on information other than the input and transform information with other pure methods. Pure functions don’t produce side effects either, meaning they don’t change state outside their own contained scope.
All of these principles contribute to a state that is easier to debug, predictable, and more elegant. How we behave and interact with information stored in this way produces behaviors that can be more easily be reasoned about.
Redux can help us manage state for React applications with the React Redux (RR) library. RR is made officially maintained by the Redux team, who created Redux for use with React. RR also implements optimizations that make it so that only the components that need to rerender do so when it actually needs to. RR is abstracting for us the optimal ways of connecting our components to our store. Here is the link to the docs. Instead of rewriting these, I would like to share with you some questions I had and what I learned based on the answers I gathered from quick chats with more senior engineers around me! Thank you, Helen and Erwins!
- Should I use
useStateif I’m using Redux?
useState is a great way to track information that you need to make a component interactive but not necessarily persistent across rerenders or after refreshing the page. For example, using this hook to control a form is the best option, there really is no point to including it in your store since it’s only useful where the form is.
- What about
These remain great tools and frankly the ones I will be making use of in my personal projects. This is because they are often not super large and a Redux store would be a little overkill. In general, when deciding which of these different features to make use of I learned to try to keep state as close to where it's needed as possible. For me this means I would approach a growing need for more easily shareable/global state incrementally, first just using state and props. Perhaps the next step is designing my components with more intention and having state be ‘up’ so that I can pass more information down.
- The React Redux docs cover a pattern of presentational and container components but show examples with using classes, is this still best practice with functional components?
The answer here is yes, maybe, depends! Quick review. Presentational components are primarily concerned with the markdown, how things look. They only receive data through props and are unaware of your larger app’s state. Container components tend to be stateful, are aware of things like Redux, and pass information to presentational components. This can still be a great pattern that helps stay organized, however, hooks make it incredibly easy to connect your store to a component. Be flexible.
Hey! Thanks a lot for reading! If you would like to help me better understand any of the things you read above feel free to message or email me! I love to be constantly improving and I would really appreciate it.