Bruno Noriller

Posted on Jun 26, 2022 • Originally published at linkedin.com

React - You might not need that many states!

#webdev #javascript #react #tutorial

You probably know not to use one single state for everything a component needs.
But in avoiding that, sometimes you feel compelled to split the state in one for each thing you need.

But you don’t need to do that!

If you have things that change together, then you end up setting a “waterfall“ of events that could be bundled together.

The form example:

Let’s say you have this form example:

function FormExample(){
    ???

    return (
        <form>
            <input name="data1" />
            <input name="data2" />
            <input name="data3" />
        </form>
    )
}

You can have it split into three states:

const [data1, setData1] = useState(data1Default)
const [data2, setData2] = useState(data2Default)
const [data2, setData3] = useState(data3Default)

But you could also:

const [allData, setAllData] = useState(dataDefault)
// and then...
const updateData = (event) => {
    setAllData((oldState) => ({
        ...oldState, 
        [event.target.name]: event.target.value
    }))
}

With this, as long as you name the inputs you can update all the state in one go.

And it doesn’t need to be a form, anywhere the data will always change together is a place you might not need to split.

And if one piece depends on another one, you would have a harder time dealing with it or having useEffects using the values as dependencies or risk having outdated data showing.

TIL: this works with nested data too!

The dependency array of hooks works with nested data [data.like.this] and not only that… even if you have data that might not be there it works!
So, you can have the state in one place and use [data?.optional?.chaining] instead of splitting or putting the entire object in the array with a if value then do stuff.

TLDR: Split if it makes sense for the data to be in different places, else, as long as it’s readable and maintainable… you might want to consider sticking to one state.

Cover Photo by Kelly Sikkema on Unsplash

Top comments (10)

Rense Bakker • Jun 27 '22

Or for forms, if you're just submitting the values and not displaying them anywhere else, you can use uncontrolled inputs! :D

function MyComponent(){
  const handleSubmit = useCallback((evt) => {
    evt.preventDefault()
    console.log(evt.target.elements.data1.value) // etc...
    // submit your data...
  }, [])

  return <form onSubmit="handleSubmit">
    <input name="data1" />
    <input name="data2" />
    <input name="data3" />
    <button type="submit">submit</button>
  </form>
}

Bruno Noriller • Jun 27 '22

Yes, but I needed an example and forms are the easiest one. =p

Rense Bakker • Jun 27 '22

Oh yes, definitely agree with the example and the point you're making! I just felt like throwing it out there as an extra gimmick, because a lot of people don't realize sometimes you don't need to use any state at all!

aben • Jun 27 '22 • Edited

For a lazy developer like me, more lean to back-end, what would you suggest to have a semi synchronous front end without diving into React or any reactive programming library, something easy to grasp, two ways binding between front and back.
One example is a toggle button that would hit an api then change say the colour of the current card (toggled).
Basically, this is achievable using fetch and this is how I'm doing it, but is there any solution out there ?

thanks a lot Bruno

Bruno Noriller • Jun 27 '22

This is a though one... with React you would have to use useEffect, useState everywhere, and personally, I'm doing the exact opposite where my backend end up as barren as possible.

The one thing that is comming to mind is to use something like Redux.
Every button clicked or action taken would dispatch something and the components would all be consuming that one state.
Even then, you would need fetches. (unless you could pull it off using websockes, but that depends on the type of project you have)

If you're already using javascript for the backend... then you might want to check Remix out because the components can end up pretty light and still react to any actions taken.

aben • Jun 28 '22

I think that's the catch. It should not be a tough one. While everyone is concerned with reactive apps while building a regular website, no one thought let's make a client-UI/Server-api two way binding for years now!

Bruno Noriller • Jun 28 '22

IMHO, I don't see a reason to put strain on a server when I can just as easily let the client handle all the state and whatever else.
I still need data from an API, but when using JAMStack, it can be basically anything.

The way you want it, it would probably be with websockets. I believe Blazor is doing something that.

aben • Jun 28 '22

Thanks 🙏 Bruno.
I never heard of ReMix but it looks cool. I will try to go through their examples

OssiDev • Jun 28 '22

I always prefer this over controlled inputs. Less code, better performance.

Bruno Noriller • Jun 27 '22

Not sure about this one...
If you have multiple source of states and each one have a name or something like data-attribute with something unique, you don't even need to know the keys from the function.
The reducer, as you added there is just another point you have to maintain.

Of course... this would be assuming you only need to do the same thing for each one.

And you could still just make { ...state, [action.type]: action.payload } maybe after filtering whatever don't fit the mold.

DEV Community

React - You might not need that many states!

The form example:

TIL: this works with nested data too!

Top comments (10)

Read next

How to persist client-side preferences on the client in Svelte (w/o DB)

To create a new Node.js project and work with dependencies, you'll need to follow these steps

Finding Which Columns Value Has Actually Changed in PostgreSQL Trigger Functions

How I Became Top Rated on UpWork