4 ms·
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 ju
by 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 agoYou 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 agoBut 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 agoI'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 agoThat's the case for useSyncExternalStore.
- talkingtab 4y agoThanks! 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.
- ttfkam 4y agoOr… y'know… just stop worrying about niggling details like this and just use Svelte. Svelte out of the box is much faster than React. You have to be well down the road of optimization before you hit parity, and optimized is almost never easier to understand. Computers don't care about code. They're satisfied with 1s and 0s. Code is for humans. The cleaner, the simpler, and the less of it, the better. More code = more bugs.
- satvikpendem 4y agoI won't use Svelte for the simple reason that I don't like templating languages. Same reason I switched from Vue to React.
- ttfkam 4y agoYou mean you like your templates to be explicitly defined as a JS/TS render function. JSX is a templating language.
- satvikpendem 4y ago> JSX may remind you of a template language, but it comes with the full power of JavaScript. [0] That's the difference. I don't want to relearn how to do for and if-statements. [0] https://legacy.reactjs.org/docs/introducing-jsx.html https://legacy.reactjs.org/docs/introducing-jsx.html
- dminik 4y agoThat's kind of funny considering you can't use `for` and `if` in JSX. I think you meant `.map` and the surprising rules of the `&&` operator.
- ttfkam 4y ago> I don't want to relearn how to do for and if-statements. …so you'll learn the weird details of render(…), learn how to manage updating a whole extra DOM on top of the existing browser DOM, learn to deal with the abstraction leaks of shouldComponentUpdate, React.PureComponent, useMemo, useCallback, and concurrent mode… …just so you can avoid learning {#if}{/if} and {#each}{/each}. Got it. TOTALLY makes sense. #StockholmSyndrome Do you put onclick handlers on your divs to go to other URLs too?
- cjblomqvist 4y agoNot OP but I think this is exactly the point. With Vue/Pinia it just works as expected without having to think about these things.