Advanced data manipulation of a synchronized server state

[czescwojtek]

Welcome! I've probably picked the wrong tools for the job I am required to do, please help me decide.

Currently, I am using react-query to fetch server state - due to the Web's nature, the data is sent in a JSON format, an array at best. As the data is fetched, I am changing its shape completely by removing duplicates, creating instances of Classes, and finally building some Maps (of <string, Class> type) based on the results. All that happens in a select function of the useQuery hook.

The moment I'm done with all the above I have to push the results to a zustand-based state as I need an option to CRUD the Map as the application runs. There are no calls to the backend to modify the data. The way it's done is idiomatic:

const { data } = useSomeQuery()

useEffect(() => {data && setZustandState(data)}, [data])

Now, I've been tasked to enrich the data even more, with another server request that needs to fire right after the first one is done, which basically means I need to build a dependent query and modify my main data in a useEffect once again (2nd. useEffect).

It crossed my mind that all the actions above do not have to, and probably shouldn't be, placed in a React component. It's basically a lot of unnecessary actions (causing rerenders) that could have been done behind the stage. And since I can't write to my store in a useQuery hook, I am leaning towards RTK Query which, if I am understanding it right, could do just that. Can anybody push me in the right direction? Is my idea about RTKQ correct?

[phryneas]

I am a bit irritated. Do you have a need for RTK Query in the first place if all you want to do is copy it over into a Zustand store? It sounds like you could simply call fetch and be done with your day.

[czescwojtek]

Let me bother you this last time to see if we are on the same page: I need a place (a store?) I can put elements into, update the existing ones, or even delete the existing ones with the exception that putting new elements can be done by firing a (cached) API request resulting in element/s data but all the other actions should remain client-only (no extra API calls on edit/delete action). I need a feature of keeping a record of the history of changes being made to the store so I can go back and forth with the actions. Each of the incoming elements needs to be initialized as a class instance before it hits the store. Keeping in mind my first message and the insights from this very post, what would you suggest I should go with? I appreciate your input, thanks!

[markerikson]

Can you clarify why "the elements need to be initialized as class instances"?

To be very clear: class instances do not belong in Redux, and generally you should not be using classes as data models with either React and Redux. Both of them assume plain JS data, immutably updated.

[czescwojtek]

Sure, no prob. The reason I use classes is that I rely quite heavily on DOM/SVG coordinates in my implementation and need to read/update them frequently. The aim is to collect all the elements in a Map<string, Element> where the Element is an ES Class with a ref: RefObject field (public ref = createRef<T>()).
Rendering of the elements actually happens when I loop over the Map object and pass down the ref prop to an actual React component: [...elements.values()].map(el => <Component ref={el.ref} />). This way, leveraging useImperativeHandle hook, I can quickly access Component internal state directly. Hopefully it makes sense without actual code.

[markerikson]

Yeah, those are not "data", and really don't belong in Redux at all. (I'll also note that getting refs to component instances should be an extremely rare thing in React. I don't want to completely sidetrack this topic, but... why are you doing that? It feels and sounds like very non-idiomatic React usage.)

[czescwojtek]

Yeah, haha. Mainly because it's one way of keeping tons of SVG elements moving in a web browser while keeping it performant at an acceptable level