4 ms·

If useEffect isn't for fetching data, what is?

satvikpendem 4y ago
It can be for fetching data: https://beta.reactjs.org/learn/you-might-not-need-an-effect#fetching-data https://beta.reactjs.org/learn/you-might-not-need-an-effect#... However most modern frameworks use something like React Query, GraphQL, etc which handles synchronizing local state with remote data for you.
- BigJono 4y ago
  Yeah and those modern frameworks use useEffect lol. This "3rd party library by default" bullshit is killing me. I just read that link, it's basically "here's a general problem with data fetching that every front ender should thoroughly understand OR actually you know what just use a fucking library and forget all about it". The React docs have been full of this rubbish for a few years now and it's just straight up irresponsible. Worry about what your own library does, and if there's footguns or complexities then explain them thoroughly. Don't just handball them off and treat your API consumers like children.
  - clayparade 4y ago
    I don't really see the issue. The page is just pointing out several anti-patterns with useEffect. The one talking about fetching data recommends a 3rd party library to make it simple but tells you how to avoid certain issues if you want to go the route of implementing your own fetching. The POST example talks about how some people will modify a state variable to tell useEffect to send a POST request when you can just do it directly. Maybe it's not to the depth of your liking but I wouldn't call them rubbish.
    - shroompasta 4y ago
      >The one talking about fetching data recommends a 3rd party library to make it simple but tells you how to avoid certain issues if you want to go the route of implementing your own fetching. yeah, making it into a custom hook lol. When did something that was originally worth 5 LOCs turn into 20 LOCs
      - javcasas 4y ago
        > When did something that was originally worth 5 LOCs turn into 20 LOCs When you want it to work properly in all the cases. That includes when new data is being fetched and you don't want to show the old data. Or when you want to not refetch data if the conditions for refetching are not met. Or when you want to cancel an in-progress data fetch if the data shall no longer be shown after fetching it because the user closed the component tasked with showing the data. I bet your 5 LOC can't do some of these things.
        shroompasta 4y ago
        >That includes when new data is being fetched and you don't want to show the old data This only really happens when you have race conditions > Or when you want to not refetch data if the conditions for refetching are not met. This only happens when you fetch based on state update on the same component > Or when you want to cancel an in-progress data fetch if the data shall no longer be shown after fetching it because the user closed the component tasked with showing the data. you can do this with certain conditionals and a cleanup function over 3 quarters of my data fetching is just a simple fetch on onComponentDidMount do you mean to tell me I have to bring in a library just for that?
        javcasas 4y ago
        > This only really happens when you have race conditions Or when the network is unpredictable, you retry because it's taking too long, then the second request succeeds, then somehow the first request succeeds. > This only happens when you fetch based on state update on the same component Or on props update. > you can do this with certain conditionals and a cleanup function That's no longer 5 LOC. > over 3 quarters of my data fetching is just a simple fetch on onComponentDidMount Congratulations. Do you also do that for authenticated requests? If so, either you are using some kind of hardcoded global variable, or you are not using 5 lines of code. > do you mean to tell me I have to bring in a library just for that? Of course not. You can implement your own library for that. Or copy-paste it all over the place. What I'm saying is that for things that are more advanced than basic data fetching, you may want to bring better tools than just fetch + 4 extra LOC.
  - fexecve 4y ago
    > This "3rd party library by default" bullshit is killing me I've noticed that new developers tend to think of libraries are indivisible units. They never stop to think what React Query uses, it's an atomic unit that you use to do queries, duh.
    - ben0x539 4y ago
      Isn't this like the whole point of abstractions? Sure they don't last forever but still.
      - fexecve 4y ago
        Well, yes, but new developers need to learn to always delve one layer beneath any abstraction they're using, and understand it. Usually they learn this the hard way by fighting with some abstraction until in a fit of insanity they dig beneath the surface (looking at the library source code or something) and realize that either (a) the docs were lying or (b) the code has a bug or (c) their understanding of what the abstraction was even capable of was wrong.
    - Rapzid 4y ago
      Yeah well React's "custom hooks" documentation doesn't help matters. In reality React doesn't expose public APIs for creating your own useEffect; just the base hooks you can compose into "composite" hooks.
- darepublic 4y ago
  > However most modern frameworks use something like React Query, GraphQL, imo most projects do not need and are made worse by that bloat.
  - scrollaway 4y ago
    I think most react-based projects that need data fetching should absolutely be using SWR (https://swr.vercel.app/ https://swr.vercel.app/). It's light enough to be worth it from a very small amount of API calls. Having caching and loading states is a significant UX bonus very quickly.
    - andix 4y ago
      Is it really lighter than react query?

It can be for fetching data: https://beta.reactjs.org/learn/you-might-not-need-an-effect#fetching-data https://beta.reactjs.org/learn/you-might-not-need-an-effect#... However most modern frameworks use something like React Query, GraphQL, etc which handles synchronizing local state with remote data for you.

BigJono 4y ago
Yeah and those modern frameworks use useEffect lol. This "3rd party library by default" bullshit is killing me. I just read that link, it's basically "here's a general problem with data fetching that every front ender should thoroughly understand OR actually you know what just use a fucking library and forget all about it". The React docs have been full of this rubbish for a few years now and it's just straight up irresponsible. Worry about what your own library does, and if there's footguns or complexities then explain them thoroughly. Don't just handball them off and treat your API consumers like children.
- clayparade 4y ago
  I don't really see the issue. The page is just pointing out several anti-patterns with useEffect. The one talking about fetching data recommends a 3rd party library to make it simple but tells you how to avoid certain issues if you want to go the route of implementing your own fetching. The POST example talks about how some people will modify a state variable to tell useEffect to send a POST request when you can just do it directly. Maybe it's not to the depth of your liking but I wouldn't call them rubbish.
  - shroompasta 4y ago
    >The one talking about fetching data recommends a 3rd party library to make it simple but tells you how to avoid certain issues if you want to go the route of implementing your own fetching. yeah, making it into a custom hook lol. When did something that was originally worth 5 LOCs turn into 20 LOCs
    - javcasas 4y ago
      > When did something that was originally worth 5 LOCs turn into 20 LOCs When you want it to work properly in all the cases. That includes when new data is being fetched and you don't want to show the old data. Or when you want to not refetch data if the conditions for refetching are not met. Or when you want to cancel an in-progress data fetch if the data shall no longer be shown after fetching it because the user closed the component tasked with showing the data. I bet your 5 LOC can't do some of these things.
      - shroompasta 4y ago
        >That includes when new data is being fetched and you don't want to show the old data This only really happens when you have race conditions > Or when you want to not refetch data if the conditions for refetching are not met. This only happens when you fetch based on state update on the same component > Or when you want to cancel an in-progress data fetch if the data shall no longer be shown after fetching it because the user closed the component tasked with showing the data. you can do this with certain conditionals and a cleanup function over 3 quarters of my data fetching is just a simple fetch on onComponentDidMount do you mean to tell me I have to bring in a library just for that?
        javcasas 4y ago
        > This only really happens when you have race conditions Or when the network is unpredictable, you retry because it's taking too long, then the second request succeeds, then somehow the first request succeeds. > This only happens when you fetch based on state update on the same component Or on props update. > you can do this with certain conditionals and a cleanup function That's no longer 5 LOC. > over 3 quarters of my data fetching is just a simple fetch on onComponentDidMount Congratulations. Do you also do that for authenticated requests? If so, either you are using some kind of hardcoded global variable, or you are not using 5 lines of code. > do you mean to tell me I have to bring in a library just for that? Of course not. You can implement your own library for that. Or copy-paste it all over the place. What I'm saying is that for things that are more advanced than basic data fetching, you may want to bring better tools than just fetch + 4 extra LOC.
- fexecve 4y ago
  > This "3rd party library by default" bullshit is killing me I've noticed that new developers tend to think of libraries are indivisible units. They never stop to think what React Query uses, it's an atomic unit that you use to do queries, duh.
  - ben0x539 4y ago
    Isn't this like the whole point of abstractions? Sure they don't last forever but still.
    - fexecve 4y ago
      Well, yes, but new developers need to learn to always delve one layer beneath any abstraction they're using, and understand it. Usually they learn this the hard way by fighting with some abstraction until in a fit of insanity they dig beneath the surface (looking at the library source code or something) and realize that either (a) the docs were lying or (b) the code has a bug or (c) their understanding of what the abstraction was even capable of was wrong.
  - Rapzid 4y ago
    Yeah well React's "custom hooks" documentation doesn't help matters. In reality React doesn't expose public APIs for creating your own useEffect; just the base hooks you can compose into "composite" hooks.
darepublic 4y ago
> However most modern frameworks use something like React Query, GraphQL, imo most projects do not need and are made worse by that bloat.
- scrollaway 4y ago
  I think most react-based projects that need data fetching should absolutely be using SWR (https://swr.vercel.app/ https://swr.vercel.app/). It's light enough to be worth it from a very small amount of API calls. Having caching and loading states is a significant UX bonus very quickly.
  - andix 4y ago
    Is it really lighter than react query?