[expo-router] Loaders don't work in layouts

[remyoudemans]

Minimal reproducible example

https://github.com/remyoudemans/expo-layout-loader-issue

Steps to reproduce

1. npm install
2. npm run web
3. Navigate to http://localhost:8081/

Environment

expo-env-info 2.0.14 environment info:
    System:
      OS: macOS 26.5
      Shell: 5.9 - /bin/zsh
    Binaries:
      Node: 22.16.0 - /Users/remy.oudemans/.nvm/versions/node/v22.16.0/bin/node
      npm: 10.9.2 - /Users/remy.oudemans/.nvm/versions/node/v22.16.0/bin/npm
    Managers:
      CocoaPods: 1.16.2 - /opt/homebrew/bin/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 25.5, iOS 26.5, macOS 26.5, tvOS 26.5, visionOS 26.5, watchOS 26.5
    IDEs:
      Android Studio: 2025.1 AI-251.26094.121.2513.14007798
      Xcode: 26.5/17F42 - /usr/bin/xcodebuild
    npmPackages:
      expo: ~56.0.9 => 56.0.9 
      expo-router: ~56.2.9 => 56.2.9 
      react: 19.2.3 => 19.2.3 
      react-dom: 19.2.3 => 19.2.3 
      react-native: 0.85.3 => 0.85.3 
      react-native-web: ^0.21.2 => 0.21.2 
    npmGlobalPackages:
      eas-cli: 16.26.0
    Expo Workflow: managed

Expo Doctor Diagnostics

21/21 checks passed. No issues detected!

Screenshots

[expo-bot]

Thank you for filing this issue!
This comment acknowledges we believe this may be a bug and there’s enough information to investigate it.
However, we can’t promise any sort of timeline for resolution. We prioritize issues based on severity, breadth of impact, and alignment with our roadmap. If you’d like to help move it more quickly, you can continue to investigate it more deeply and/or you can open a pull request that fixes the cause.

[hassankhan]

Hi @remyoudemans, loaders are not supported in _layouts and instead should be defined in the route that uses them.

[remyoudemans]

Hi @hassankhan, if that's an intentional design decision, I would definitely vote to overturn it.
It goes against prior art in this area:

• tanstack-router and remix allow loaders in layouts (and in __root for tanstack)
• though not a recommended pattern, Next.js pages router allows getInitialProps in _app https://nextjs.org/docs/pages/building-your-application/routing/custom-app#getinitialprops-with-app
• Next.js app router has a root layout that is a react server component, so root-level data fetching can be done there.

Is there another way to fetch data or access server environment variables at the root level for all pages?

Failing that, documenting this design decision (and justifying it) would be great.

[hassankhan]

Layout loaders are currently a deliberate omission in our data loaders implementation; could you share more about the use-cases you'd like to use them in?

As a sidenote, I'll improve the docs to mention this limitation, thanks for opening the issue.

[remyoudemans]

Thanks @hassankhan!

Our current use-case would be for loading server env vars. We'll be deploying our expo web site as a container in kubernetes. I know that the more usual approach is to build the site once for staging and once for prod and let expo inline the EXPO_PUBLIC_ env vars for each, but what we would like to do is to build a single docker image for both staging and prod and load the env vars that we want into the front-end by using a loader to fetch them from the server and put them into a global React context that can be accessed everywhere.
This is a pattern that we do in Next.js apps with getInitialProps in _app in the pages router or using a server component layout passing the env vars into a client component context in the app router.
It's a bit unorthodox, but it guarantees that it's exactly the same build across staging and prod.

The only way I can imagine doing this without layout loaders would be something like this

// utils
export default function createEnvLoader(wrappedLoader: LoaderFunction = () => ({})) {
  const newLoader: LoaderFunction = async (request, params) => {
    const wrappedLoadedData = await wrappedLoader(request, params);

    return {
      ...wrappedLoadedData,
      HELLO_WORLD: process.env.HELLO_WORLD,
    }
  }

  return newLoader;
}

// in every page, so env vars can be accessed in any component
export const loader = createEnvLoader();

// or 
export const loader = createEnvLoader(async () => {
  // some page-specific loader here
});

Aside from that use-case, I can imagine a lot of scenarios where you might want some dynamic content in the root layout for your whole app/website, in the header, footer or nav, like having the customer's name or profile picture in the header. Or in a layout scoped just to some pages.