|
| 1 | +--- |
| 2 | +title: clientLoader |
| 3 | +--- |
| 4 | + |
| 5 | +# `clientLoader` |
| 6 | + |
| 7 | +In addition to (or in place of) your [`loader`][loader], you may define a `clientLoader` function that will execute on the client. |
| 8 | + |
| 9 | +Each route can define a `clientLoader` function that provides data to the route when rendering: |
| 10 | + |
| 11 | +```tsx |
| 12 | +export const clientLoader = async ({ |
| 13 | + request, |
| 14 | + params, |
| 15 | + serverLoader, |
| 16 | +}: ClientLoaderFunctionArgs) => { |
| 17 | + // call the server loader |
| 18 | + const serverData = await serverLoader(); |
| 19 | + // And/or fetch data on the client |
| 20 | + const data = getDataFromClient(); |
| 21 | + // Return the data to expose through useLoaderData() |
| 22 | + return data; |
| 23 | +}; |
| 24 | +``` |
| 25 | + |
| 26 | +This function is only ever run on the client, and can used in a few ways: |
| 27 | + |
| 28 | +- Instead of a server action for full-client routes |
| 29 | +- To use alongside a `clientLoader` cache by invalidating the cache on mutations |
| 30 | + - Maintaining a client-side cache to skip calls to the server |
| 31 | + - Bypassing the Remix [BFF][bff] hop and hitting your API directly from the client |
| 32 | +- To further augment data loaded from the server |
| 33 | + - I.e., loading user-specific preferences from `localStorage` |
| 34 | +- To facilitate a migration from React Router |
| 35 | + |
| 36 | +## Hydration Behavior |
| 37 | + |
| 38 | +By default, `clientLoader` **will not** execute for the route during initial hydration. This is for the primary (and simpler) use-case where the `clientLoader` does not change the shape of the server `loader` data and is just an optimization on subsequent client side navigations (to read from a cache or hit an API directly). |
| 39 | + |
| 40 | +```tsx |
| 41 | +export async function loader() { |
| 42 | + // During SSR, we talk to the DB directly |
| 43 | + const data = getServerDataFromDb(); |
| 44 | + return json(data); |
| 45 | +} |
| 46 | + |
| 47 | +export async function clientLoader() { |
| 48 | + // During client-side navigations, we hit our exposed API endpoints directly |
| 49 | + const data = await fetchDataFromApi(); |
| 50 | + return data; |
| 51 | +} |
| 52 | + |
| 53 | +export default function Component() { |
| 54 | + const data = useLoaderData<typeof loader>(); |
| 55 | + return <>...</>; |
| 56 | +} |
| 57 | +``` |
| 58 | + |
| 59 | +### `clientLoader.hydrate` |
| 60 | + |
| 61 | +If you need to run your `clientLoader` on hydration, you can opt-into that by setting `clientLoader.hydrate=true`. This will tell Remix that it needs to run the `clientLoader` on hydration. A common use-case for this is to prime a client-side cache with the data loaded on the server: |
| 62 | + |
| 63 | +```tsx |
| 64 | +export async function loader() { |
| 65 | + const data = await getDataFromDB(); |
| 66 | + return json(data); |
| 67 | +} |
| 68 | + |
| 69 | +let isInitialHydration = true; |
| 70 | +export async function clientLoader({ serverLoader }) { |
| 71 | + if (isInitialHydration) { |
| 72 | + isInitialHydration = false; |
| 73 | + // This will resolve with the hydrated server data, it won't fetch() |
| 74 | + const serverData = await serverLoader(); |
| 75 | + cache.set(cacheKey, serverData); |
| 76 | + return serverData; |
| 77 | + } |
| 78 | + |
| 79 | + const cachedData = await cache.get(cacheKey); |
| 80 | + if (cachedData) { |
| 81 | + return cachedData; |
| 82 | + } |
| 83 | + |
| 84 | + const data = await serverLoader(); |
| 85 | + cache.set(cacheKey, data); |
| 86 | + return data; |
| 87 | +} |
| 88 | +clientLoader.hydrate = true; |
| 89 | + |
| 90 | +export default function Component() { |
| 91 | + const data = useLoaderData<typeof loader>(); |
| 92 | + return <>...</>; |
| 93 | +} |
| 94 | +``` |
| 95 | + |
| 96 | +<docs-info>If a route exports a `clientLoader` and does not export a server `loader`, then `clientLoader.hydrate` is automatically treated as `true` since there is no server data to SSR with. Therefore, we always need to run the `clientLoader` on hydration before rendering the route component.</docs-info> |
| 97 | + |
| 98 | +### HydrateFallback |
| 99 | + |
| 100 | +If you need to avoid rendering your default route component during SSR because you have data that must come from a `clientLoader`, you can export a [`HydrateFallback`][hydratefallback] component from your route that will be rendered during SSR, and only once the clientLoader runs on hydration will your router component be rendered. |
| 101 | + |
| 102 | +## Arguments |
| 103 | + |
| 104 | +### `params` |
| 105 | + |
| 106 | +This function receives the same [`params`][loader-params] argument as a [`loader`][loader]. |
| 107 | + |
| 108 | +### `request` |
| 109 | + |
| 110 | +This function receives the same [`request`][loader-request] argument as a [`loader`][loader]. |
| 111 | + |
| 112 | +### `serverLoader` |
| 113 | + |
| 114 | +`serverLoader` is an asynchronous function to get the data from the server `loader` for this route. On client-side navigations, this will make a [fetch][fetch] call to the Remix server loader. If you opt-into running your `clientLoader` on hydration, then this function will return you the data that was already loaded on the server (via `Promise.resolve`). |
| 115 | + |
| 116 | +[loader]: ./loader |
| 117 | +[loader-params]: ./loader#params |
| 118 | +[loader-request]: ./loader#request |
| 119 | +[hydratefallback]: ./hydrate-fallback |
| 120 | +[bff]: ../guides/bff |
| 121 | +[fetch]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API |
0 commit comments