Hacker News Reader

Comment by the_gipsy | Hacker News Reader

How do you handle route changes and data fetching, then? Back to Redux?

Those are results from a change in state, nothing to do with whether a component has appeared.

You either have some world state, like redux, or you have react components with hooks. With hooks, those have everything to do with the component's lifecycle. Hooks are included with react, world state management is not.

What? You still use hooks with Redux. And you could consider React's Context API as world state management if you really wanted to.

And these still aren't intrinsically tied to a component lifecycle.

Sorry I meant useEffect.

See react's official docs https://react.dev/reference/react/useEffect#what-are-good-al...

They recommend using react-query (a cached fetching library) and react-router. This combination definitely uses lifecycles to fetch data in the render functions.

Except I don't think they're using or thinking in terms of "lifecycles".

With react-query for example, when you use useQuery it communicates behind the scenes via Context with the react-query singleton. It doesn't fetch data because a component has rendered, it does so because a useQuery function call has asked for data it doesn't have in its cache.

That may result from a component rendering for the first time, or because that component's props changed, or because some piece of state somewhere in the app changed, etc etc. In the end it doesn't matter. It's not about a component's "lifecycle", it's responding to a change in lowercase-s state.

It absolutely does fetch because it has rendered. The route changes (or user clicks, whatever), a new component renders and it fetches the first time it renders. This is not a technicality, which is why the thing is called useEffect.

It does not fetch without rendering, once.

Except your first useQuery call happens before the component it’s in even returns any JSX for React to render.

And you don’t need a useEffect to do this sort of thing. You just need a function that creates a promise keyed to whatever identifier you passed in and some state to hold its status and result.

After the component gets mounted, in render code.

Yes you don't need useEffect. But the alternative is something like redux, where you're components are not (self-contained) components anymore. And the docs recommend effectful libraries.

A component can't render before it's generated markup to render.

And no, you don't need useEffect or Redux. You need a promise and some state to track it. Things like react-query aren't "effectful".

> A component can't render before it's generated markup to render.

So nothing ever renders.

> And no, you don't need useEffect or Redux. You need a promise and some state to track it. Things like react-query aren't "effectful".

Of course a Promise is a side effect. You're talking bullshit.

Things render after they've generated what they want to render, not before. If you want to render the result of 2 + 2, you have to run that calculation before you can render the result. When you call useQuery, you immediately and synchronously get the status of that query so that you can use it when generating the JSX you're returning to render.

And a side effect and useEffect are not at all the same thing. You're conflating generic software terms with APIs that have very specific meanings and functions within React.

And if instead of calculating 2+2 you call into some world state (or return a deferred call along with your JSX, doesn't matter), then that is a side effect. Period. The main effect is returning JSX (html and some event->callback descriptors), which could be pure.

useEffect is a side effect in a render function. Not all side effects are useEffect in a render function, good job.

Not sure how this got so absurdly reductionist. The fact remains, you do not need to use useEffect to fetch data in React. And useEffect runs after rendering, so you'd be delaying the fetch for no reason.

Never left

Same boat. It's tiring watching other React devs tie themselves in knots over component lifecycle (either via hooks or class lifecycle methods) when the actual solution is to use neither.

It's downright pleasant, with typescript. All the "waaaah boilerplate" stuff goes away. It's very simple (not even hard to reimplement, in a pinch). Truly does work well with non-React codebases, so if you build your business logic or at least your client-code around it, it's portable.

I stopped being a React fan with hooks, but remain a fan of Redux.

Reply on news.ycombinator.com