5 ms·

React documentation lists a lot of other use cases for useEffect() than just that: - useEffect is a React Hook that lets you synchronize a component with an ex

by kennu 3y ago

React documentation lists a lot of other use cases for useEffect() than just that: - useEffect is a React Hook that lets you synchronize a component with an external system. - Connecting to an external system - Wrapping Effects in custom Hooks - Controlling a non-React widget - Fetching data with Effects - Specifying reactive dependencies - Updating state based on previous state from an Effect - Removing unnecessary object dependencies - Removing unnecessary function dependencies - Reading the latest props and state from an Effect - Displaying different content on the server and the client https://react.dev/reference/react/useEffect#specifying-reactive-dependencies https://react.dev/reference/react/useEffect#specifying-react...

scotty79 3y ago
Just because you can doesn't mean you should. What you should have gotten from this list of every possible use (and misuse) of useEffect is that it's for interaction with external things. And if you are doing a lot of interafacing with external stuff you should use a dedicated service for it, not pollute your code with ad-hoc bits of interaction, each wrapped in their own bespoke useEffect(). And the linked section talks about specifying dependencies of the code block inside useEffect() You don't define dependencies WITH useEffect. You define dependencies OF useEffect. And you don't have much choice in the matter. Any local variable (also parameter) of render function needs to be a dependency of useEffect code. As this section states. Here are some common misuses: https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect
- kennu 3y ago
  You can overuse useEffect() for sure. But I don't know how else you'd react e.g. to the page query string parameters or component properties changing, when the rendered content depends on them.
  - scotty79 3y ago
    You use a router or you have a service that watches history api and dispatches Redux actions. React is UI library. Just because it can do a lot doesn't mean it should do everything. Especially in larger apps.
    - kennu 3y ago
      Yeah and then the router sends you property changes which you react to with useEffect().
      - scotty79 3y ago
        The whole point is not to use it directly in your components. It is implementation detail of that particular router. You might use router that interfaces with Redux not React directly. Or you could write your router in the form of a service that lives directly in the history api event handlers and communicates directly though react state setters of some top-level component. Not a single useEffect needed. Besides, router doesn't usually send you anything. It just sets props on your components according to url.
        kennu 3y ago
        Okay, but my point is that somewhere along the line there always is a useEffect() that reacts to something. Maybe it's in your own component, maybe it's in a third party component.
        scotty79 3y ago
        I don't agree with your point. You can use state setter from outside of react and inside react rely only on state and props and not use useEffect() at all. You don't need useEffect() to react to anything. React itself reacts to state and props change. You'll do yourself a favor if you ban yourself from using state setters inside useEffect(). Try it.
        kennu 3y ago

by kennu 3y ago

scotty79 3y ago

Just because you can doesn't mean you should. What you should have gotten from this list of every possible use (and misuse) of useEffect is that it's for interaction with external things. And if you are doing a lot of interafacing with external stuff you should use a dedicated service for it, not pollute your code with ad-hoc bits of interaction, each wrapped in their own bespoke useEffect(). And the linked section talks about specifying dependencies of the code block inside useEffect() You don't define dependencies WITH useEffect. You define dependencies OF useEffect. And you don't have much choice in the matter. Any local variable (also parameter) of render function needs to be a dependency of useEffect code. As this section states. Here are some common misuses: https://react.dev/learn/you-might-not-need-an-effect https://react.dev/learn/you-might-not-need-an-effect

kennu 3y ago
You can overuse useEffect() for sure. But I don't know how else you'd react e.g. to the page query string parameters or component properties changing, when the rendered content depends on them.
- scotty79 3y ago
  You use a router or you have a service that watches history api and dispatches Redux actions. React is UI library. Just because it can do a lot doesn't mean it should do everything. Especially in larger apps.
  - kennu 3y ago
    Yeah and then the router sends you property changes which you react to with useEffect().
    - scotty79 3y ago
      The whole point is not to use it directly in your components. It is implementation detail of that particular router. You might use router that interfaces with Redux not React directly. Or you could write your router in the form of a service that lives directly in the history api event handlers and communicates directly though react state setters of some top-level component. Not a single useEffect needed. Besides, router doesn't usually send you anything. It just sets props on your components according to url.
      - kennu 3y ago
        Okay, but my point is that somewhere along the line there always is a useEffect() that reacts to something. Maybe it's in your own component, maybe it's in a third party component.
        scotty79 3y ago
        I don't agree with your point. You can use state setter from outside of react and inside react rely only on state and props and not use useEffect() at all. You don't need useEffect() to react to anything. React itself reacts to state and props change. You'll do yourself a favor if you ban yourself from using state setters inside useEffect(). Try it.
        kennu 3y ago