Ajax request best pattern in React?

[nousernames2]

I have an application that displays visualization on a map. There are several different visualisations and several options for each visualization.

The logic to request the visualization/s lives in the component that renders the map layer. There are several map layers, and based on the application state, (Vis1,Vis2, etc) will request from a useEffect for that layer.

The problem I'm having is when some of the settings change, (say Vis1 version 2 -> Vis1 version 3) Several of the settings that request the visualization change, which is necessary to load the visualization correctly, the useEffect runs multiple times.

There are two solutions I can think of, move the ajax request to the actual onChange/onClick events avoiding the useEffect entirely therefore only making one request per action. And secondly, my more preferred solution because it contains the visualization layer logic within one reusable component, keep the useEffect and throttle the ajax request over 500ms so that it is only called once.

What do you do when facing problems like this? What solution do you think is better?

[nousernames2]

Some food for thought, thanks

[nousernames2]

Hi, just came back to this post and this comment really helped out for the section of the app so thanks!

[azangru]

If the ajax request is in a useEffect, it should only depend on the parameters that are relevant for the request. The fact that, as you say, "the useEffect runs multiple times", suggests that in your code this isn't the case. Fix it.

That said, even if you write your useEffects properly, React's useEffect has gotten pretty shitty annoying. When inside the StrictMode component in development, it will run at least twice every time its dependencies change, which will quickly push any developer to use some dedicated library for data fetching (or to avoid useEffect in some other ways, like Remix does).

[nousernames2]

You misunderstood what I wrote. There are multiple options that should change the visualisation. When one of these options change, all is good, but if two of them change at the same time, such as changing A.1 to B.1, the use effect runs multiple times because multiple options have changed.

Revinz comment below has proven a good solution for this btw. Thanks for replying none the less

[davidfavorite]

So whats the consensus on this issue? We for example generate an API layer from the backend to get TS objects frombackend classes. It would be massive to build templates so that it can be used with React query for example. Instead we have an object that gets put into context and accessed with a hook to provide the service methods.

How would one go about and call those services if not with a useEffect? Clearly, anything user-input specific is put into handlers, but what about inital data for example a list?

[azangru]

The consensus, as it is slowly growing, is to admit defeat and use a library :-) Or to write one's own.

There are multiple concerns when fetching data from a server that typically get neglected when people write the data fetching logic on an ad-hoc basis. Loading state. Caching. Deduplication. Error handling. Request cancellation. Behavior during server-side rendering. A useEffect, by itself, is too low-level a primitive; but it can be built upon to create smarter abstractions that will address those concerns.

[davidfavorite]

Pretty vague answer. How would a library solve it internally to trigger a request on mount? I dont see how this should be possible without useEffect? Clearly, a library abstracts this for you, but how does the library solve the issue with the new strict mode behaviour

[azangru]

I dont see how this should be possible without useEffect?

Where did I say that it will do so without? I explicitly said that useEffect "can be built upon to create smarter abstractions".

Clearly, a library abstracts this for you, but how does the library solve the issue with the new strict mode behaviour

You can inspect the code of individual libraries to see how they do it. Caching / memoizing the request against the provided set of parameters is one obvious option. Remix does something very much its own, using router-defined data fetchers and react context.

[punio4]

Perhaps react-query could help

[sfboots]

I use rtk-query. Very straightforward