Zustand vs Context

[Naomak]

In Part "Why zustand over context?" is mentioned: "Renders components only on changes".

What is meant by that in details? With context provider, it also rerenders only those components where useContext is used and its value has changed. Or am I missing something?

[drcmda]

Context renders all consumers throughout the system on every change. In a larger scale app everything, the entire component tree, will render on every keystroke when you update an input field for instance. And there is little you can do about it, you can't easily bail out of updates and you can't tie components to specific state. Unless you split the context state up, which leads to even worse problems. At this point larger scale apps will eventually just fail because they have been made rigid and implicit.

Assuming you have a state model { cats: 1, dogs: 2 } and you have two components, one prints the amount of cats, another the amount of dogs, with context no matter what you do, both components will render always. But with zustand you do this:

function Dogs() {
  // This component will *only* render when the amount of dogs changes
  const dogs = useStore(state => state.dogs)
  return <div>{dogs}</div>
}

This article is a great summary: https://formidable.com/blog/2021/stores-no-context-api

Symptoms which may include, but are not limited to:

Implicit dependencies between providers
Implicit provider dependencies for storybook implementations and unit tests
Performance bottlenecks from provider value updates
Excessive application wide re-renders

This is the official stance from the React team:

Don't use Context if it's not different per subtree, [..] use Context to expand the scope of things included in that. E.g. wrapping two things that by default have their own state to make them share state.

In other words, only use context for compound components where A relies on the presence of B, for instance List > ListItem.

[max-ch9i]

I've re-read the tweets many times and still find them hard to understand exactly.

@drcmda You concluded that according to @sebmarkbage, context is best used for compound components, but I wonder if you can share your thoughts on what you think each of the sentences below means?

Don't use Context if it's not different per subtree

What is 'it'? The value of the context not different? What does it mean to be different "per subtree"?

If it needs to be semi-local state, you can always default to very local state and use Context to expand the scope of things included in that.

What is a 'semi-local' and 'very local' states? What does it mean to expand the "scope"? What is meant by 'that' in 'inlcuded in that'?

[dai-shi]

What does it mean to be different "per subtree"?

It roughly means to have multiple Providers or one Provider but not meaningfully at root.

<App>
  <Provider>
    <Foo>
      <Provider>

What is a 'semi-local'

I think it just means a parent component has a state and pass it to children with context.

<Parent>
  ...
  <Child1>
  ...
  <Child2>

[max-ch9i]

The example for multiple Providers helps a lot! Thanks for taking time to respond @dai-shi

[zecka]

Note that with extra effort, it's possible to prevent re-rendering when using the Context API.

You can create a "connect" function that take a selector and component as parameter an return a memoized component:

(Anyway, I will definitely use Zustand on my project 😄 )

Create the "connect" function

// context-helper.tsx
import React from 'react'
const ConnectContext = <ComponentProps extends {}>() => <Selector extends (...args: any[]) => any>(
  select: Selector,
  WrappedComponent: (
    props: ReturnType<Selector> &
      ComponentProps & { children?: React.ReactNode }
  ) => any
): any => {
  const MemoWrapper = React.memo(WrappedComponent);
  return (props: ComponentProps) => {
    const selectors = select();
    return <MemoWrapper {...selectors} {...props} />;
  };
};

Then use it in your component

// MyComponent.tsx
import React from "react";
import { ConnectContext } from "./context-helpers";
import { useDemoContext } from "./DemoContext";

const Select = () => {
  const { setFirst, second } = useDemoContext();
  return { setFirst, second };
};
type MyComponentProps = {};

export const MyComponent = ConnectContext<MyComponentProps>()(
  Select,
  ({ setFirst, second }) => {
    console.log("MY COMPONENT RENDER");
    return (
        <div>
        <h3>This component will not rerender even if you change "first" value</h3>
        second value {second}
        <button onClick={() => setFirst(Math.random() * 100)}>
          Set first to random
        </button>{" "}
      </div>
    );
  }
);

Here is a codesandbox demo: https://codesandbox.io/s/react-context-avoid-too-much-rendering-thxgf3

[dai-shi]

That should work. I'd prefer component composition to HoC. Here's my old blog post: https://blog.axlight.com/posts/4-options-to-prevent-extra-rerenders-with-react-context/

There might be some limitations. For example, you can’t use hooks.

[gabrielmlinassi]

I only use context for compound composition pattern. Ex:

<Menu>
  <Menu.Button>...</Menu.Button>
  <Menu.Items>
    <Menu.Item>...</Menu.Item>
    <Menu.Item>...</Menu.Item>
  </Menu.Items>
</Menu>

...

const MenuButton = () => ...
const MenuItems = () => ...
const MenuItem = () => ...
const Menu = () => ...

Menu.Button = MenuButton
Menu.Items = MenuItems
Menu.Item = MenuItem

[ccreusat]

Hi !

What would you use for the user / session / theme globa data shared among components in an app?

We use Context for complex components and compound pattern in our react components library.

We use zustand in our apps.

We have a context / provider for globals (user, theme) but I was thinking about switching to zustand an having a store for each.

Same, thinking about having a store to handle our toast notifications.

What are you thinking people ?