State management & data heavy loaders #10049
Unanswered
povilasDadelo
asked this question in
Q&A
Replies: 1 comment 2 replies
-
The That said, using useState is not a bad thing, use the simplest solution, and if useState is the simplest one then use that. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
To persist some app state remix offers to save it to Cookies. In the docs same Cookies example it also touches on the optimistic UI approach. I have implemented state saving logic like shown in the example, but now I see that it causes my page to re-render a lot. Also the loader on this specific route is quite heavy & some other limitation introduced by business decision's is preventing from refactoring it any time soon. So now I have this issue that when user updates checkbox value that has to be persisted it triggers revalidation of that loader which is very slow. Some solutions that I have thought about:
First one is to use shouldRevalidate function to prevent loader from running again. But then I have to keep standard useState hook to manage state and directly return the state along with the updateState function. I have Client side state & some state in Remix server Cookies. Then use shouldRevalidate to control if it should re-run. Code for hook look like this:
Second one is to use a dedicated resource route (mentioned in Remix docs) to update state. Then all over my codebase I have to use useRouteLoaderData to access that state. I found some opinions that using resource routes in such a liberal way might be an anti-pattern in the context of remix.
I am rather lost which would be best approach or maybe I am missing something. All opinions are welcome!
Beta Was this translation helpful? Give feedback.
All reactions