5 ms·

I work with React (NextJS) and from working on things in Vue, and Nuxt - the one thing I absolutely hate about React is state management. If you have never used

I work with React (NextJS) and from working on things in Vue, and Nuxt - the one thing I absolutely hate about React is state management. If you have never used Pinia[0] (Vuex) with Vue, it's just so, so, so much easier. I'm using Zustand[1] with React as it is as similar as I can find to Pinia, but the whole hook system is just painful to work with... OK rant over. I haven't built anything substantial with Svelte, but it's definitely on the radar, and I like how similar it is to Vue single file components (SFC). Hoping state management will be as nice to work with as Pinia is with Vue. [0] https://pinia.vuejs.org/ https://pinia.vuejs.org/ [1] https://github.com/pmndrs/zustand https://github.com/pmndrs/zustand

azangru 4y ago
I don't get it. From the example on Stackblitz[0], Pinia looks pretty much like redux, only with multiple stores instead of a single one. As far as I recall, Zustand is similar. What are the advantages of these libraries over redux (especially, the modern and opinionated redux-toolkit)? 0 - https://stackblitz.com/github/piniajs/example-vue-3-vite https://stackblitz.com/github/piniajs/example-vue-3-vite
- akaike 4y ago
  I don't get it either. Plus, what exactly is so hard about using hooks? Hooks are awesome.
  - shanehoban 4y ago
    I think that when you work with a framework like Vue/Nuxt where hooks aren't needed, they are not so awesome when you transition to working with React/Next. Everything just works as expected (with Vue/Nuxt).
  - azangru 4y ago
    > what exactly is so hard about using hooks Oh, this I can tell. For one thing, it's very easy to get stale closures if one isn't careful. For another, hooks are a reactivity mechanism that is tied to the re-rendering of the whole component (what if you don't want to re-render the component? what if you only want to perform a side effect when a particular value changes?). Third, the docs are sowing confusion by discouraging the very natural, and often inevitable, concept of side effects, as well as by removing the concept of component's lifecycle (there is no idiomatic way of telling react to please run certain logic only once when the component mounts)[0]. 0 - https://react.dev/learn/reusing-logic-with-custom-hooks#keep-your-custom-hooks-focused-on-concrete-high-level-use-cases https://react.dev/learn/reusing-logic-with-custom-hooks#keep...
    - schwartzworld 4y ago
      > what if you only want to perform a side effect when a particular value changes? https://react.dev/reference/react/useEffect https://react.dev/reference/react/useEffect That is literally what useEffect is for! Describe your side effect, provide a list of values that you want the hook to watch for when they change. `useEffect(someEffect, [value1, value2, value3])` > the very natural, and often inevitable, concept of side effects React uses a functional programming model. Always has. Watch the Honeypot React documentary and notice how many times the earliest adopters say they were excited to have way to express UIs functionally. Functional programmers believe in minimizing side effects. If you don't like the paradigm, there are 1000 other UI frameworks that use an imperative model. Complaints like yours read like someone complaining that their screwdriver isn't a hammer.
      - brucou 4y ago
        I beg to differ here. Or let's say that the React "functional programming" model has very little to do with the actual functional programming done by actual functional programmers. What is true is that React components are functions. But functional programming and programming with functions are two different things. Second, side effects are just about in every React component where you use a hook. Third, (hypothesis) `useEffect` is probably a misnomer that stick there because it would be a breaking change to rename it to something more proper. Words and bickering aside, you can write great applications with React, that's fact. It is also a fact that a lot of folks are using it wrong, which shows either a problem with React learnability itself, or with its documentation, or well, with the programmers themselves.
        schwartzworld 4y ago
        > side effects are just about in every React component where you use a hook. I would expect most of your side effects to happen as a result of user interaction, i.e. in an event handler. Data fetching would probably be at the top of the tree. What side effects are you including in every component? > a problem with React learnability itself, or with its documentation, or well, with the programmers themselves All three! - Most programmers dont learn FP before adopting React, which means they aren't going have a more difficult time working with React's functionalish model. - Lots of blog posts, tutorials and even docs of popular libraries feature poorly written React code. It's just reality. Lots of people use this library, and there's no barrier to entry to write a tutorial post. IMO, the new React docs are a step in the right direction and should be a primary learning material for most.
- shanehoban 4y ago
  I guess my main gripes are not with the libraries for state management themselves, but how managing rendering after state mutations occur. Pinia and Vue/Nuxt just do this effortlessly. Having to deal with hooks and useEffect in React is just a pain... in my opinion.
  - lozenge 4y ago
    You shouldn't use useEffect just to bring state mutations from the store into the component or to calculate "view model" from your state. Have a look at the new react docs. https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect
    - talkingtab 4y ago
      But then again, you might need an effect. The behind the scenes (or behind the hooks) complexity that react adds in order to the make DOM thing work then makes it difficult when you do need an effect. Things like WebRTC or sockets or some such. useRef? useState? I have found this to be extremely difficult. If someone knows a good resource for doing things like this in React (and not a one page file, but with multiple components etc) I would appreciate knowing about it.
      - johtso 4y ago
        I'd say pull that logic out of your components and put it in some central place like an XState machine exposed to your components through Context.
      - lozenge 4y ago
        That's the case for useSyncExternalStore.
        talkingtab 4y ago
        Thanks! Just what I needed. On a side note, is there a place that talks about this issue in React and explains why this is needed? There is a hint in the doc. It says "... that hold state outside of React". Using web sockets, events come in and some (and only some )affect components. When a socket is connected there is an explicit state that changes, but how that gets into React-Land is difficult. The same issue exists with WebRTC. What I don't really get is why useRef, useState and useEffect are so difficult to get right.
sergioisidoro 4y ago
I have used MobX state tree (MST) with react, and a lot of the concepts are the same with Pinia. Pinia still looks better, I totally agree here.
koch 4y ago
I agree about pinia. After redux and selectors and reducers and spread syntax and immer and all that stuff, using pinia with vue3 was an absolute joy.
agumonkey 4y ago
It's a strange feel with the vue world. There's a natural simplicity to it. While react often creates slightly(or a lot) complex entities that cause a lot of friction. Vue is often criticized for not being true js in the end etc etc but it doesn't seem to be important when creating something.
artdigital 4y ago
I went through similar troubles, then ended up trying [react-query](https://tanstack.com/query/v3/ https://tanstack.com/query/v3/) and now I don't bother anymore. React Query does everything I need, and if for some reason I still need separate state management, I use useContext for those parts React Query is a joy to use and clicks very nicely with how I am structuring my apps, building around interacting with async things like APIs
Rapzid 4y ago
I use MobX with Vue and React; works great; decoupled from any UI library ecosystem and is transferable knowledge.

azangru 4y ago

I don't get it. From the example on Stackblitz[0], Pinia looks pretty much like redux, only with multiple stores instead of a single one. As far as I recall, Zustand is similar. What are the advantages of these libraries over redux (especially, the modern and opinionated redux-toolkit)? 0 - https://stackblitz.com/github/piniajs/example-vue-3-vite https://stackblitz.com/github/piniajs/example-vue-3-vite

akaike 4y ago
I don't get it either. Plus, what exactly is so hard about using hooks? Hooks are awesome.
- shanehoban 4y ago
  I think that when you work with a framework like Vue/Nuxt where hooks aren't needed, they are not so awesome when you transition to working with React/Next. Everything just works as expected (with Vue/Nuxt).
- azangru 4y ago
  > what exactly is so hard about using hooks Oh, this I can tell. For one thing, it's very easy to get stale closures if one isn't careful. For another, hooks are a reactivity mechanism that is tied to the re-rendering of the whole component (what if you don't want to re-render the component? what if you only want to perform a side effect when a particular value changes?). Third, the docs are sowing confusion by discouraging the very natural, and often inevitable, concept of side effects, as well as by removing the concept of component's lifecycle (there is no idiomatic way of telling react to please run certain logic only once when the component mounts)[0]. 0 - https://react.dev/learn/reusing-logic-with-custom-hooks#keep-your-custom-hooks-focused-on-concrete-high-level-use-cases https://react.dev/learn/reusing-logic-with-custom-hooks#keep...
  - schwartzworld 4y ago
    > what if you only want to perform a side effect when a particular value changes? https://react.dev/reference/react/useEffect https://react.dev/reference/react/useEffect That is literally what useEffect is for! Describe your side effect, provide a list of values that you want the hook to watch for when they change. `useEffect(someEffect, [value1, value2, value3])` > the very natural, and often inevitable, concept of side effects React uses a functional programming model. Always has. Watch the Honeypot React documentary and notice how many times the earliest adopters say they were excited to have way to express UIs functionally. Functional programmers believe in minimizing side effects. If you don't like the paradigm, there are 1000 other UI frameworks that use an imperative model. Complaints like yours read like someone complaining that their screwdriver isn't a hammer.
    - brucou 4y ago
      I beg to differ here. Or let's say that the React "functional programming" model has very little to do with the actual functional programming done by actual functional programmers. What is true is that React components are functions. But functional programming and programming with functions are two different things. Second, side effects are just about in every React component where you use a hook. Third, (hypothesis) `useEffect` is probably a misnomer that stick there because it would be a breaking change to rename it to something more proper. Words and bickering aside, you can write great applications with React, that's fact. It is also a fact that a lot of folks are using it wrong, which shows either a problem with React learnability itself, or with its documentation, or well, with the programmers themselves.
      - schwartzworld 4y ago
        > side effects are just about in every React component where you use a hook. I would expect most of your side effects to happen as a result of user interaction, i.e. in an event handler. Data fetching would probably be at the top of the tree. What side effects are you including in every component? > a problem with React learnability itself, or with its documentation, or well, with the programmers themselves All three! - Most programmers dont learn FP before adopting React, which means they aren't going have a more difficult time working with React's functionalish model. - Lots of blog posts, tutorials and even docs of popular libraries feature poorly written React code. It's just reality. Lots of people use this library, and there's no barrier to entry to write a tutorial post. IMO, the new React docs are a step in the right direction and should be a primary learning material for most.
shanehoban 4y ago
I guess my main gripes are not with the libraries for state management themselves, but how managing rendering after state mutations occur. Pinia and Vue/Nuxt just do this effortlessly. Having to deal with hooks and useEffect in React is just a pain... in my opinion.
- lozenge 4y ago
  You shouldn't use useEffect just to bring state mutations from the store into the component or to calculate "view model" from your state. Have a look at the new react docs. https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect
  - talkingtab 4y ago
    But then again, you might need an effect. The behind the scenes (or behind the hooks) complexity that react adds in order to the make DOM thing work then makes it difficult when you do need an effect. Things like WebRTC or sockets or some such. useRef? useState? I have found this to be extremely difficult. If someone knows a good resource for doing things like this in React (and not a one page file, but with multiple components etc) I would appreciate knowing about it.
    - johtso 4y ago
      I'd say pull that logic out of your components and put it in some central place like an XState machine exposed to your components through Context.
    - lozenge 4y ago
      That's the case for useSyncExternalStore.
      - talkingtab 4y ago
        Thanks! Just what I needed. On a side note, is there a place that talks about this issue in React and explains why this is needed? There is a hint in the doc. It says "... that hold state outside of React". Using web sockets, events come in and some (and only some )affect components. When a socket is connected there is an explicit state that changes, but how that gets into React-Land is difficult. The same issue exists with WebRTC. What I don't really get is why useRef, useState and useEffect are so difficult to get right.

sergioisidoro 4y ago

I have used MobX state tree (MST) with react, and a lot of the concepts are the same with Pinia. Pinia still looks better, I totally agree here.

koch 4y ago

I agree about pinia. After redux and selectors and reducers and spread syntax and immer and all that stuff, using pinia with vue3 was an absolute joy.

agumonkey 4y ago

It's a strange feel with the vue world. There's a natural simplicity to it. While react often creates slightly(or a lot) complex entities that cause a lot of friction. Vue is often criticized for not being true js in the end etc etc but it doesn't seem to be important when creating something.

artdigital 4y ago

I went through similar troubles, then ended up trying [react-query](https://tanstack.com/query/v3/ https://tanstack.com/query/v3/) and now I don't bother anymore. React Query does everything I need, and if for some reason I still need separate state management, I use useContext for those parts React Query is a joy to use and clicks very nicely with how I am structuring my apps, building around interacting with async things like APIs

Rapzid 4y ago

I use MobX with Vue and React; works great; decoupled from any UI library ecosystem and is transferable knowledge.