Comment by docmars

My issue with React Context is you can only assign initial state through the `value` prop on the provider if you need that initial state to be derived from other hook state/data, which requires yet another wrapper component to pull those in.

Even if you make a `createProvider` factory to initialize a `useMyContext` hook, it still requires what I mentioned above.

Compare this to Vue's Pinia library where you can simply create a global (setup) hook that allows you to bring in other hooks and dependencies, and return the final, global state. Then when you use it, it points to a global instance instead of creating unique instances for each hook used.

Example (React cannot do this, not without enormous boilerplate and TypeScript spaghetti -- good luck!):

  export const useMyStore = defineStore("myStore", () => {
    const numericState = ref(0);
    const computedState = computed(() => reactiveState.value * 2);
    const numberFromAnotherHook = useAnotherHook();
    
    const { data, error, loading } = useFetch(...);

    const derivedAsyncState = computed(() => {
      return data.value + numericState.value + numberFromAnotherHook.value;
    });

    return {
      numericState,
      computedState,
      numberFromAnotherHook,
      derivedAsyncState,
    }
  });

This is remarkably easy, and the best part is: I don't have to wrap my components with another <Context.Provider> component. I can... just use the hook! I sorely wish React offered a better way to wire up global or shared state like this. React doesn't even have a plugin system that would allow someone to port Pinia over to React. It's baffling.

Every other 3rd party state management library has to use React Context to initialize store data based on other React-based state/data. Without Context, you must wait for a full render cycle and assign the state using `useEffect`, causing your components to flash or delay rendering before the store's ready.

I think it's a matter of taste and preference mostly, but I like Vue's overall design better. It uses JS Proxies to handle reactive state (signals, basically) on a granular level, so entire component functions don't need to be run on every single render — only what's needed. This is reflected in benchmarks comparing UI libraries, especially when looking at table row rendering performance.

Their setup (component) functions are a staging ground for wiring up their primitives without you having to worry about how often each call is being made in your component function. Vue 3's composition pattern was inspired by React with hooks, with the exception that variables aren't computed on every render.

And I agree about Suspense, it's a confusing API because it's yet-another-way React forces you to nest your app / component structure even further, which creates indirection and makes it harder to tie things together logically so they're easier to reason about. The "oops, I forgot this was wrapped with X or Y" problem persists if a stray wrapper lives outside of the component you're working on.

I prefer using switch statements or internal component logic to assign the desired state to a variable, and then rendering it within the component's wrapper elements -- states like: loading, error, empty, and default -- all in the same component depending on my async status.