State management & data heavy loaders

[povilasDadelo]

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:

import { useFetcher } from '@remix-run/react'
import { useState } from 'react'

export function usePersistedState<T>(initialState: T, key: string) {
  const fetcher = useFetcher()
  const [state, setState] = useState<T>(initialState)

  // Function to update state and sync with server
  const updateState = (newState: T) => {
    setState(newState)
    fetcher.submit({ state: { [key]: newState } as JsonObject }, { method: 'POST', encType: 'application/json' })
  }

  return [state, updateState] as const
}

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!

[sergiodxa]

The useRouteLoaderData won't give you access to the resource route data, that only gives you access to the matching UI routes, you would have to use useFetcher to access the resource route data.

---

That said, using useState is not a bad thing, use the simplest solution, and if useState is the simplest one then use that.

[LauryKa]

I think what @povilasDadelo meant was that he has UI with frequent interactions that must be persisted, thus being submitted via fetcher.submit. Also in same route loader he calls heavy external API, just to have the data around like in SPA context. Now problem is that loader function is being executed too frequently and unnecessary calls is made to external API. Should this fetching external API be done elsewhere? Say in resource routes?

[HriBB]

I think I had the same problem and solved it by splitting the route into layout and route.

In the layout, I load all the "heavy" data that never changes. And in the route, I load data, that changes frequently.

Think of it as the "root" loader, where you load translations and other global data. Depending on your use case, you might need several parent loaders ...

I am posting this from my mobile device, so I cannot attach any code examples. Let me know if you need them ;)