Personally I think the use of what state management library I use is largely dependent on the size of the web application I'm building.
For small and medium applications I don't think Redux or any other state management tool is worth the overhead and I usually find it easier to just stick with react state and hooks.
However when an application has a lot of state and especially state that needs to spread across multiple components in a way where it becomes hard to have it passed down this is usually when I turn to state management libraries.
I do agree with the cache usage argument although for some applications I think storage of data retrieved is needed if you need to transform it in some way.
For me Id use the example of having to pass loading state around. Usually loading state is modified in multiple different components but the loading overlay is quite high up in the component tree. It then ends up being tricky to modify its state in a clean way and not having to have multiple loading components. (It could just be the case I don't know how to handle this type of thing correctly though)
Hi! Thank you for taking the time to read and comment.
I do agree with the cache usage argument although for some applications I think storage of data retrieved is needed if you need to transform it in some way.
We're not constrained to cache the data as it arrives from the server. Both SWR and React Query take any async function (i.e. a function returning a Promise) as argument. This means you can write a function that calls fetch or axios awaits the call, then transforms the data and returns it.
This way cache will contain the transformed data instead; and we don't need to involve a state-management library only for that.
Ah I see that's quite a clean way of dealing with it I might have to look more into that. Is the idea to always use a cache retreval rather than holding in directly in state? Or do think there is a use case for holding it in state? (In your opinion)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Personally I think the use of what state management library I use is largely dependent on the size of the web application I'm building.
For small and medium applications I don't think Redux or any other state management tool is worth the overhead and I usually find it easier to just stick with react state and hooks.
However when an application has a lot of state and especially state that needs to spread across multiple components in a way where it becomes hard to have it passed down this is usually when I turn to state management libraries.
I do agree with the cache usage argument although for some applications I think storage of data retrieved is needed if you need to transform it in some way.
How would you describe a moment when it's becoming hard? What does it mean?
For me Id use the example of having to pass loading state around. Usually loading state is modified in multiple different components but the loading overlay is quite high up in the component tree. It then ends up being tricky to modify its state in a clean way and not having to have multiple loading components. (It could just be the case I don't know how to handle this type of thing correctly though)
Hi! Thank you for taking the time to read and comment.
We're not constrained to cache the data as it arrives from the server. Both SWR and React Query take any async function (i.e. a function returning a Promise) as argument. This means you can write a function that calls
fetchoraxiosawaits the call, then transforms the data and returns it.This way cache will contain the transformed data instead; and we don't need to involve a state-management library only for that.
Ah I see that's quite a clean way of dealing with it I might have to look more into that. Is the idea to always use a cache retreval rather than holding in directly in state? Or do think there is a use case for holding it in state? (In your opinion)