Bad habits, we all have them! In this article, I will confess some of my own coding bad habits and bad habits I have encountered in React code over the past years, working as a React dev.

1. Create derived state using a side effect

This is something that happens a lot. Usually because initially some values were fetched from an api and it seemed logical to add up the values from the api call in the same useEffect:

1function ShoppingCart({ items }: { items: Array<{ name:string, price: number }> }){
2  const [totalPrice, setTotalPrice] = useState(0)
3
4  useEffect(() => {
5    // suppose there was initially an API call here, which fetched the items
6    const sum = items.reduce((current, item) => current += item.price, 0)
7    setTotalPrice(sum)
8  }, [items])
9
10  return <ul>
11    {items.map((item, index) => <li key={index}>{name} - {price}</li>
12    <li>Total: {totalPrice}</li>
13  </ul>
14}
15

However, setting derived state inside a useEffect hook should be avoided at all times! Instead, what we want is the useMemo hook:

1function ShoppingCart({ items }: { items: Array<{ name:string, price: number }> }){
2  const totalPrice = useMemo(() => items.reduce((current, item) => current += item.price, 0), [items])
3
4  return <ul>
5    {items.map((item, index) => <li key={index}>{name} - {price}</li>
6    <li>Total: {totalPrice}</li>
7  </ul>
8}
9

This saves us an extra rerender that would be triggered if we change the state inside a side-effect that is based on some other state. Saving one rerender does not seem like a big deal, but it adds up quickly if the component gets nested inside another component that also sets derived state in a useEffect etc...

2. Managing multiple state properties

Creating forms is something we do a lot and it usually looks something like this:

1function ContactForm(){
2  const [email, setEmail] = useState('')
3  const [name, setName] = useState('')
4
5  const handleSubmit = useCallback(() => {
6    // submit data...
7  }, [])
8
9  return <form onSubmit={handleSubmit}>
10    <input value={email} onChange={e => setEmail(e.target.value)} />
11    <input value={name} onChange={e => setName(e.target.value)} />
12    <button type="submit">submit</button>
13  </form>
14}
15

And we all know what happens when someone asks us if we can add another field to the form... we add another useState and another input and call it a day. I've done this myself, but the question becomes, when do we stop? Because obviously, it is really dirty to have 20 lines of useState hooks in one component. If a component has more than one state property, use a reducer instead! I know reducers have this bad reputation of being complicated and redux-y, but it is actually one of the simplest ways to manage several state properties in a single component:

1const initialState = {
2  email: '',
3  name: ''
4}
5
6function formReducer(prevState: typeof initialState, nextState: Partial<typeof initialState>){
7  // no need for redux-like switch statements here!
8  // just spread the next state onto the previous one, and we're done.
9  return { ...prevState, ...nextState }
10}
11
12function ContactForm(){
13  const [{ email, name }, setValue] = useReducer(formReducer, initialState)
14
15  const handleSubmit = useCallback(() => {
16    // submit data...
17  }, [])
18
19  return <form onSubmit={handleSubmit}>
20    <input value={email} onChange={e => setValue({ email: e.target.value })} />
21    <input value={name} onChange={e => setValue({ name: e.target.value })} />
22    <button type="submit">submit</button>
23  </form>
24}
25

3. Creating black box context providers

Suppose we have some app context that we use to share some settings with the components in our app. This is a pretty common pattern and normally there's nothing wrong with it. However, there are some dangerous pitfalls here! Take this provider for example:

1const initialState = {
2  darkMode: true
3}
4
5function settingsReducer(prevState: typeof initialState, nextState: Partial<typeof initialState>){
6  return { ...prevState, ...nextState }
7}
8
9const AppSettings = React.createContext({
10  settings: initialState,
11  changeSettings: (() => {}) as (settings: Partial<typeof initialState>) => void
12})
13
14function useAppSettings(){
15  return useContext(AppSettings)
16}
17
18function AppSettingsProvider({ children }: React.PropsWithChildren<unknown>) {
19  const [settings, changeSettings] = useReducer(settingsReducer, initialState)
20
21  useEffect(() => {
22    // some side effect, for example:
23    settings.darkMode && import ('../styles/darkMode.css')
24  }, [settings.darkMode])
25
26  return <AppSettings.Provider value={{ settings, changeSettings }}>
27    {children}
28  </AppSettings.Provider>
29}
30

It might seem logical, but when we do this, we need to realize that other developers working on our application are not going to realize this side effect exists there. In general, side effects in providers should be avoided. A provider is a blackbox except for the values that we expose from it (the context value). What we can do instead (in this case), is create a new component with an explicit name like DarkModeThemeLoader which only handles the loading of the darkMode styles, so other developers working on our app do not have to guess where this logic lives:

1function DarkModeThemeLoader(){
2  const { settings } = useAppSettings()
3
4  useEffect(() => {
5    settings.darkMode && import ('../styles/darkMode.css')
6  }, [settings.darkMode])
7
8  return null
9}
10
11// usage example:
12function App(){
13  return <AppSettingsProvider>
14    <DarkModeThemeLoader />
15    ... other content ...
16  </AppSettingsProvider>
17}
18