Hacker News Reader

Comment by clayparade | Hacker News Reader

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.

View on HN

>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

> 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.

>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?

> 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.

>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 has an atomically low chance of ever happening, and never happening on single threaded monolithic servers.

>That's no longer 5 LOC.

Okay cool, 7-8 LOC, better than abstracting it into a whole new custom hook.

>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.

You need to be more specific about authenticated requests, because cookies that are sent back as a response will have directions on how they should be sent back to the server on each request that requires no javascript at all.

If you're using token auth with localStorage, which probably isn't a wise idea because you're now susceptible to XSS attacks, then you should already be abstracting that away.

>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.

here's a pastebin of my wrapper around requests

https://pastebin.com/V33F1f2F

it is already highly configured and abstracted.

All i want to do in the useEffect is await api.getGamesByDate(), and this should be fine.

What you're suggesting is that you support the React team's decision in that I have to have an additional wrapper around my apiCalls just to avoid two fetch calls in Strict Mode.

Does that sound logical to you?

Congratulations on your code! You created apiCall, effectively your own library for doing requests. The very same thing that you ought to banish.

Once you have setup that library (or hook) yes, using it it's indeed 4 lines of code. That also happens for libraries constructed by others.

Reply on news.ycombinator.com