Imposed cognitive load of creating a simple React/Redux component
When I first started learning React/Redux, I created this diagram to help me understand all the different boilerplates I needed to write in order to make a React component. I don't think this is how things should work, whatever the scale is.
Context and useState serve me well so far. What do you do that justifies the use of redux and nothing simpler?
Redux was super confusing and seemed overcomplicated when I first started using it too. However, it comes in handy when working with Firebase. It helps keep track of firebase authentication, database connections and listeners, and firing events by dispatching an action. The npm package I use includes all the reducers one needs for Firebase and is abstracted away from you so you don't have to worry about it.
Using Redux is better now as they added hooks. You can use hooks like useSelector and useDispatch in combination with functional components which makes Redux a lot more developer friendly. Plus, I really like the Redux dev tools which help a lot with debugging.
This comment was deleted 5 years ago
https://github.com/prescottprue/react-redux-firebase
I am a React developer, when I started class components was what was available at the time, with Redux.
I am currently on the process of trying out react-hooks.
Exhibit A:
Redux is excellent way to store normalized data, centralize it and make it aviable to componenta i your application. You m8ght have the followng scenario:
Component A is loaded, as part of displaying it calls an api to get data it requires.
Then, Component B, which is not directly related to Component A, needs the same information, which now can access from redux store to immediately show it to the user, while also making an api call to get the latest data.
Exhibit B:
You want separate components to react to an event somewhere. For example, user makes an action, while activity history, notifications bage, and confirmation toast are in display and need to perform a certain action.
Exhibit C:
I have seen an example where because redux is basically used in all components, it can virtually recover the entire application's state.
At the end of the day, redux is just tool/pattern. You may not need it at all in simple scenarios. Its about preferences and using it where it makes sense.
Huh. The way I deal with the first two scenarios you described is to create an observable class that represents the data, and also contains methods to manipulate the data (perhaps by invoking firebase/apis or just in-memory change). The class instance is made available to anyone using createContext. Any component who wishes to be informed of changes to that class instance can just call useContext to get it, then invoke subscribe on it. Unsubscribe is returned from the subscribe method, which can be passed to useEffect/useCallback for invocation during unmount. This approach makes more sense to me as it leverages existing concepts (context and observables), instead of a complicated web of named terms from redux. I don't have to litter my codebase with boilerplates or separate files just for adding a simple action. I just have to introduce two files: a file containing the class definition, and another file that provides the react hook for providing and exposing the class instance.
As for the third scenario, yeah, that is indeed pretty neat.
I agree, it's a tool/pattern, but one which I feel is not needed yet in my toolbox.
Not a fan of Redux either. Context and useState work great for me.
Hi Gabe! Divjoy is pretty great! I learned a lot from your hook articles, and love the way you structure and write your code.
Thanks so much! Happy to hear you've found the usehooks articles useful.
I have have been using React for 5 years and never was a fan of Redux. I use Apollo and local state in graphql queries when needed.
Same. This and Context for managing local state for multiple components. Ex logged in state.