Why does "loader" execute on client side?

[r07r07]

While exploring the React Router example from https://github.com/remix-run/react-router/tree/main/examples/ssr-data-router, I encountered an unexpected behavior: the loader function is executing on the client side instead of the anticipated server side. This behavior is not ideal and may lead to security concerns.

Reproduce:

1. Download the example from https://github.com/remix-run/react-router/tree/main/examples/ssr-data-router
   and do some modification:
   1. add "type": "module" to package.json
   2. use import instead of require in server.js
   3. add the line console.log("Home Loader") into homeLoader function
2. Build and run:

$ npm run build
$ npm run start

After clicking the Home link, "Home Loader" is logged in the browser console. This indicates that the loader function is executing on the client side, which is unexpected and should be avoided. Ideally, the loader function and action function should be excluded from the client bundle.

The guide said:

Remix uses "tree shaking" to remove server code from browser bundles.

So it seems the loader function was not tree shaken off in this example.

How can I fix this?

[webfueler]

I am also using react-router lastest version with data router, and loaders only run server side on the first request. From that point on, loaders and actions run in client side. In Remix, this is not the case - a fetch call is made to the server, and loaders and actions always run server side.

I also checked the server bundle, and I see the loader and action functions there.

Is it possible to force data router to always use loaders and actions server side? If so, can we get an updated example or some directions on how to do it?

[iamdey]

I just started to put my hands into this (so my understanding is not full yet).

Well as far as I understand the process, one difference between framework and library modes are the dataStrategy:

The difference between modes

Framework mode uses getSingleFetchDataStrategy

https://github.com/remix-run/react-router/blob/a920753e30c05c95e875bc656031519f8b437b6d/packages/react-router/lib/dom-export/hydrated-router.tsx#L210C5-L210C17

// framework mode 

let router = createRouter({
  …
  dataStrategy: getSingleFetchDataStrategy(
      () => router,
      (routeId: string) => {
        …

Note that getSingleFetchDataStrategy is currently exported as UNSAFE_getSingleFetchDataStrategy.

Library mode (default) will use defaultDataStrategyWithMiddleware (and defaultDataStrategy) by default

react-router/packages/react-router/lib/router/router.ts

Line 837 in a920753

let dataStrategyImpl = init.dataStrategy || defaultDataStrategyWithMiddleware;

Reproduce the framework behavior

Note: loaders will be “fetched” as a specific API by the client e.g.

createBrowserRouter([
  {
   path: '/foo'
   loader: () =>({ message: 'hello' }),
  }], {
    dataStrategy: async (args) => {
       // override loaders here according to your needs
       // The following is a dumb example and should not be used as it is
       const { matches } = args;
       const toLoad = matches.filter(m => m.shouldLoad);

       // replace the execution of loaders and actions by BFF  calls
       const bffCalls = toLoad.map(async m => [
          m.route.id,
          await m.resolve(async (fn) => {
            // fn will call the loader or the action
            // just bypass it and create a call to your BFF
            // (obviously you need to handle this call on your custom server)
            return (await fetch(`${routerOptions.basename}/${m.pathname}.data`)).json();
          }),
        ]);

        // format the results for dataStrategy
        return (await Promise.all(bffCalls).reduce((acc, curr) ({
          ...acc,
          [curr[0]]: curr[1],
        }, {});
    }
})

react-router/packages/react-router/lib/router/utils.ts

Line 378 in a920753

export interface DataStrategyFunction<Context = DefaultContext> {

Note that default data strategy and getSingleFetchDataStrategy used in framework mode sound pretty massive.

Deep dive

Both strategy will resolve the matching route in a different way.

framework

react-router/packages/react-router/lib/dom/ssr/single-fetch.tsx

Line 349 in a920753

m.resolve(async (handler) => {

Note the resolver is overwritten here.

And will use fetchAndDecodeViaTurboStream

react-router/packages/react-router/lib/dom/ssr/single-fetch.tsx

Line 518 in a920753

let res = await fetch(url, await createRequestInit(request));

Library mode (default)

react-router/packages/react-router/lib/router/router.ts

Line 5240 in a920753

let results = await Promise.all(matchesToLoad.map((m) => m.resolve()));

Then both methods call callLoaderOrAction (Note the comment bellow) cf.

react-router/packages/react-router/lib/router/router.ts

Line 5626 in a920753

async function callLoaderOrAction({

// Default logic for calling a loader/action is the user has no specified a dataStrategy

I stop digging here, I just saw that that route match's loader has been rewritten with a function named singleFetch at run time which is defined by the data strategy configuration.

[sergiodxa]

That example uses React Router with a custom SSR setup

It's not using Remix or React Router framework mode

That's the reason why loaders are running server and client side

[iamdey]

Thank you for this clear answer.

I think the misunderstanding comes from the document where there no clean line between server-side and client code in the documentation.

For example, in https://reactrouter.com/how-to/client-data we believe loader is only called server side (and also because clientLoader exists).

Honestly I hope it's just matter of time and effort that we can have an utility that we can plug on a custom SSR in order to have something close to the framework mode.
This would prevent to have weird hacks in loaders and become a technical debt nightmare with next versions of react-router.

That said, thank you again for the good work.