Like many a React developer who preferred function components to classes, I was excited to begin implementing React Hooks upon their release in early 2019. Upon reflection of over a year spent consistently writing stateful function components, much has changed in my philosophy on how I approach such an implementation.
My first attempts were quite inelegant. I began building a component, and when I needed a state variable, I called useState. When I needed a second state variable, I called it again. And again. And again.
Let's take the example of a registration form with numerous controlled inputs and a modal that appears on a certain user action (maybe their password is invalid). Let's say we also have a toggle that allows the user to switch the form between light mode and dark mode. After a while, the top of such a component often begins to look like this:
"This is too many calls to useState; the top of my component is cluttered and repetitive," I would decide. "Time to convert this to use the useReducer hook." Although I often end up preferring the useReducer hook, my reasoning has evolved, and the false dichotomy I had created about being forced to choose between the two has shifted into a new and better understanding: often times, using both hooks in one component is the best answer.
Let's again look at our registration form with a modal. Armed with our philosophy of "combine multiple useState calls when we've exceeded an arbitrary number of them", we proceed with refactoring our component to no longer require useState.
Okay; we refactored some things. Did we improve our component? By which metric did we improve or get worse? The answer becomes clearer when we begin to modify our component (or, better yet, when a teammate goes to modify it later).
A teammate is given this component and asked to add a Reset button to the form. If provided the first version, the result would likely look like this:
That looks rather suboptimal. Wouldn't it be nice if we could batch those calls to set fields into a single command? Naturally, that's exactly what we do with the useReducer version of the component:
Great! Thanks, teammate!
Now you've reset the form to light mode. :facepalm:
Perhaps I'm not giving this imaginary teammate enough credit. Perhaps they looked at initialState and saw that the darkMode boolean was included (not to mention the modal visibility boolean). In that case, they may have written their reducer solution to look like this:
This brings us back to our question: did we make our component better when we moved every useState call into a single useReducer? I would posit that we have not. We've simply moved the verbosity from the top of the component to the state/reducer portion of our file. Additionally, we're mixing concerns. The form inputs' contents need not know the color scheme of the page and vice versa (nor is the visibility of the modal inherently tied to the form's values).
A clever developer might suggest this as an alternative:
Clever as this may be, we're still mixing concerns and not giving a person new to this component the best chance of understanding the functionality with the least amount of difficulty.
Let us finally arrive at what I believe to be the optimal solution: useState for singleton state variables combined with a useReducer for state variables that are associated with one another or dependent on one another in some way.
Your average React developer who has worked with Hooks even a little will likely grasp this component and be able to add functionality or debug issues with much less difficulty than any of the previous examples (and less likelihood of adding new bugs themselves).
Do you agree? Disagree? Do you have an even better approach that I haven't discovered? Drop me a line. :)