0 - https://stackblitz.com/github/piniajs/example-vue-3-vite
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.
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.
JSX is a templating language.
That's the difference. 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?
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...
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.
No, sorry; for useEffect to fire, a prop or a state needs to change; which means that the component is going to re-render. My point is that sometimes we want to observe properties passed to the component for side-effect purposes without re-rendering the component.
> Functional programmers believe in minimizing side effects.
In order to do something — anything — in the real world, we need side effects. Even Haskellers know this :-)
> In order to do something — anything — in the real world, we need side effects. Even Haskellers know this :-)
Hence the use of the word "minimize"
Let computers do what they're good at so that we devs can concentrate on the actual problems being solved.
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.
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.
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
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/
[1] https://github.com/pmndrs/zustand