4 ms·

This isn't a recent development. People misusing useEffect just to update state has been a thing in React since they were introduced, even though a close readin

This isn't a recent development. People misusing useEffect just to update state has been a thing in React since they were introduced, even though a close reading of the original hooks docs should have conveyed that that's not what they're for. I think the new docs certainly make it clearer what the correct usage is, so now lots of people are finding out that their mental model isn't quite right. Some of this predates the introduction of hooks, as much of the useEffect misuse is identical to the way people misused componentDidMount/componentDidUpdate/componentWillUnmount. I don't think you're right to say that you should almost never use them. You should use them for doing the things which they're designed for, like attaching event listeners or dealing with timers (neither of which are that unusual in my experience). But like I said, they've never been a tool for dealing with rerenders, and the React team has been trying to explain this to people for ages. The original docs did explain this, but it was less clear than the new ones.

quickthrower2 3y ago
As a misuser on hobby projects, what is the best way to do an initial API call once the main component has mounted? I was using useEffect, with the deps being the things sent to the query.
- rimunroe 3y ago
  For what it's worth, "the deps being the things sent to the query" is fundamentally correct. What were you doing wrong before and what are you doing now? There are alternatives to making queries with useEffect which can result in a better user experience. Were you alluding to those? One of the sources of confusion I see the most around effects is that people still think of them in terms of components mounting and unmounting. However, effects only care about running, cleaning up, and maybe needing to run again. I can't think of a case when they'd need to know about the component's mount/unmount behavior. For effects, the main things to consider are: • Can this effect be fired unconditionally, and if not, what could change in the system to make its result inconsistent/outdated with the new state of the system? • What cleanup does this effect need?
- moritzwarhier 3y ago
  It seems mostly expected to have a framework or library in place that takes care of data fetching for the root component. The new docs emphasize this, I guess mostly to make users think twice about building their own hook and to make it easy to move initial data fetching to the server. Frameworks include next.js, remix or vite-plugin-ssr (the last one is maybe an outlier, as it deems itself a library). Often fetching is tied to routing, which makes sense. If routing is not needed, AFAIK the go-to solutions right now are react-query or SWR. https://swr.vercel.app/ https://swr.vercel.app/ react-query has a nice comparison table for data fetching libraries: https://tanstack.com/query/v4/docs/react/comparison https://tanstack.com/query/v4/docs/react/comparison If routing only takes place on the client, react-router also includes data fetching features: https://reactrouter.com/en/main/guides/data-libs https://reactrouter.com/en/main/guides/data-libs I don't know how well react-router fits with SSR. If none of that fits and the requirements are either very simple or very custom, it should still be possible to manually pass props to the root component. Looking this up in the docs, the big caveat of this unconventional approach is that props would not be reactive, the root component would have to be manually re-rendered: https://react.dev/reference/react-dom/client/createRoot#updating-a-root-component https://react.dev/reference/react-dom/client/createRoot#upda...
franciscop 3y ago
Exactly, this is the same as saying Redux has two methodologies, the "setter system" and the "event system"; since it wasn't that well documented initially doesn't mean that the setter way was ever recommended (it's not). In fact if you watched the Flux youtube talk, something highly recommended to learn the philosophy behind Redux, it was pretty clear. Edit: here's the video (from 10:20) https://www.youtube.com/watch?v=nYkdrAPrdcw https://www.youtube.com/watch?v=nYkdrAPrdcw

quickthrower2 3y ago

As a misuser on hobby projects, what is the best way to do an initial API call once the main component has mounted? I was using useEffect, with the deps being the things sent to the query.

rimunroe 3y ago
For what it's worth, "the deps being the things sent to the query" is fundamentally correct. What were you doing wrong before and what are you doing now? There are alternatives to making queries with useEffect which can result in a better user experience. Were you alluding to those? One of the sources of confusion I see the most around effects is that people still think of them in terms of components mounting and unmounting. However, effects only care about running, cleaning up, and maybe needing to run again. I can't think of a case when they'd need to know about the component's mount/unmount behavior. For effects, the main things to consider are: • Can this effect be fired unconditionally, and if not, what could change in the system to make its result inconsistent/outdated with the new state of the system? • What cleanup does this effect need?
moritzwarhier 3y ago
It seems mostly expected to have a framework or library in place that takes care of data fetching for the root component. The new docs emphasize this, I guess mostly to make users think twice about building their own hook and to make it easy to move initial data fetching to the server. Frameworks include next.js, remix or vite-plugin-ssr (the last one is maybe an outlier, as it deems itself a library). Often fetching is tied to routing, which makes sense. If routing is not needed, AFAIK the go-to solutions right now are react-query or SWR. https://swr.vercel.app/ https://swr.vercel.app/ react-query has a nice comparison table for data fetching libraries: https://tanstack.com/query/v4/docs/react/comparison https://tanstack.com/query/v4/docs/react/comparison If routing only takes place on the client, react-router also includes data fetching features: https://reactrouter.com/en/main/guides/data-libs https://reactrouter.com/en/main/guides/data-libs I don't know how well react-router fits with SSR. If none of that fits and the requirements are either very simple or very custom, it should still be possible to manually pass props to the root component. Looking this up in the docs, the big caveat of this unconventional approach is that props would not be reactive, the root component would have to be manually re-rendered: https://react.dev/reference/react-dom/client/createRoot#updating-a-root-component https://react.dev/reference/react-dom/client/createRoot#upda...

franciscop 3y ago

Exactly, this is the same as saying Redux has two methodologies, the "setter system" and the "event system"; since it wasn't that well documented initially doesn't mean that the setter way was ever recommended (it's not). In fact if you watched the Flux youtube talk, something highly recommended to learn the philosophy behind Redux, it was pretty clear. Edit: here's the video (from 10:20) https://www.youtube.com/watch?v=nYkdrAPrdcw https://www.youtube.com/watch?v=nYkdrAPrdcw