state management and architecture decision

[buenaflor]

No description provided.

[markus2330]

I tend to agree with the decisions but some explanations etc. is missing.

[markus2330]

Ideally you already add to doc/architecture the main choices&differences to Bulletproof React, otherwise it is only a half decision.

[Bushuo]

Hi, I heard great things about Zustand but never used it myself. I usually just went with Apollo Client as I mostly developed my personal React applications with a GraphQL backend.

But I would like to point out, that I would not use Zustand in the way it is currently used inside the seeds feature.
React Query is a better tool for handling server state.

Just a quick pointer about state.
We can usually distinguish between three types of state inside a React application.

1. Local Component State -> is the dropdown open or not, is the checkbox clicked or not, and so on.
   I would use the default react useState for this or Context + useReducer for more complex local state

2. Application State -> Synchronous State. Local user preferences, UI state in a visual desgin app
   This is where 'Zustand' should be used

3. Server State -> Async state. A network request is needed before any state can be derived.
   I would use 'React Query' for this.

My rationale for this is, React Query has integrated mechanisms for network error states, deduping, retries, optimistic ui and so on. Thus much of the wiring code that would be needed in the local state management approach is just included.

Here is the documentation that points out the differences to local state management tools
https://react-query-v3.tanstack.com/guides/does-this-replace-client-state
And a quick 100 second summary of React Query
https://www.youtube.com/watch?v=novnyCaa7To
A blog post of the official maintainer, he is also based in Vienna 🎉
https://tkdodo.eu/blog/practical-react-query
Official Docu, I think they renamed it to tanstack/query for version 4
https://tanstack.com/query/latest/docs/react/overview

Edit: added useful links

[buenaflor]

@Bushuo Yup, makes sense and I agree with this.

[markus2330]

We can usually distinguish between three types of state inside a React application.

Please write this in the beginning of the decision to clarify the context what gets decided.

Edit: added useful links

Please also add then to either #43 or the decision (if they are specific to understand the decision and not really relevant to get started with PermaplanT).

[absurd-turtle]

@Bushuo

Yes, it makes perfect sense to distinguish between the "types" of state.
I separated the concerns in the decision document.
Do you have any insights on why to use React Query specifically as opposed to vercel/swr for example?

[Bushuo]

@Bushuo

Yes, it makes perfect sense to distinguish between the "types" of state. I separated the concerns in the decision document. Do you have any insights on why to use React Query specifically as opposed to vercel/swr for example?

@absurd-turtle Yup, swr is more minimalistic for easy use cases. React Query also has for example, builtin features for pagination. I think in our case a more holistic solution should be preferred.

[markus2330]

@Bushuo please also add all the details you know about the different state libs. Feel free to push here.

[Bushuo]

Hi @markus2330

Please also add all the details you know about the different state libs. Feel free to push here.

The ones I know of are either already included (Redux), or related to GraphQL.
I think the decision is ready to be merged.

[markus2330]

Great work, good that we looked into this again!