DEV Community

Bruno Noriller
Bruno Noriller

Posted on • Originally published at Medium

React: State X Derived State

What’s a derived state? Think one state for text and then another for uppercaseText.

Derived State

function Foo() {
    const [text, setText] = useState('hello, za warudo!');
    const [uppercaseText, setUppercaseText] = useState(text.toUpperCase());

    useEffect(() => {
        setUppercaseText(text.toUpperCase());
    }, [text])

    ...
}
Enter fullscreen mode Exit fullscreen mode

Putting like that it’s crazy to think anyone would do this… right? RIGHT?

Yes, an example like this will make clear that this is wrong.

The Bad of Derived State

  • Stored separately and out-of-sync with the actual state.
  • Triggers (depend) on unnecessary re-renders.

How to refactor the derived state?

Say it’s an expensive calculation… the solution is to use useMemo.

function Foo() {
    const [text, setText] = useState('hello, za warudo!');
    const uppercaseText = useMemo(() => text.toUpperCase(), [text]);
    ...
}
Enter fullscreen mode Exit fullscreen mode

How to quickly spot state that can be derived?

I came up with a good way of thinking that should make it easier to KNOW if a state should be “another state” or just a computed property (memorized or not depending on the case).

function Foo({
    text = 'hello, za warudo!',
    uppercaseText = text.toUpperCase(),
}) {
    ...
}

// Forget react for a moment...
// Would you ever call a function like this?
const text = 'hello, za warudo!';
Foo({
    text,
    uppercaseText: text.toUpperCase(),
});
Enter fullscreen mode Exit fullscreen mode

If you think of those states as “props”, then this makes it more blatantly what it should be.

Forget React entirely, think only of functions:
Would you call a function with a variable and then another variable you could just compute inside?

Top comments (0)