[RFC] File system-based routing

[EvanBacon]

✅ Complete

Expo Router v1 is now available! The v2+ roadmap is available here.

RFC

The entire contents of this repo are up for discussion. We are releasing the beta early and in a very volatile state! Please do not depend on this library in your production apps yet!

The most important part of the API is the routes convention as this cannot easily change after it's been locked in.

Routes convention:

• Layout routes: Parent routes that host child routes. These are defined by creating a _layout file in in any directory in the app directory.
• Child routes: A route that has no nested children. Defined as a file in the app directory.
• Fragment routes: Nested routes that don't add a path component to the route.
• Dynamic routes: A child or layout route that matches all unmatched routes at a given segment level (AKA: slug).
• Deep dynamic routes: A child or layout route that conforms to all unmatched segments in a URL (AKA: wildcard, splat, optional catch-all).
• Index routes: A child route named index.js which doesn't add any segment to the URL.

Built-in layouts:

• To support complex native paradigms like stacks, tabs, drawers, etc. expo-router wraps and re-exports React Navigation navigators which can be used in layout routes.

If you have comments or concerns please leave them below and I'll try to answer whatever I can.

[danscan]

I've been eagerly awaiting expo/router, and so far it looks incredible.

I'm curious if it's possible to fully configure reachable routes using files in the app directory, which would include specifying screen options.

For example, instead of specifying screens and their options in a layout file, imagine a convention where route files exported a NavigationOptions:

// (root).tsx
// Provides the layout of the descendant matched routes, which in this case renders children in a native stack
export default function Layout({ children }: LayoutProps) {
  return (
    <NativeStack>
      {children}
    </NativeStack>
  );
}

// my-route.tsx
export default function MyRoute() {
  return (
    <Text>This is my route</Text>
  );
}

// my-route specifies its own navigation options, rather than me having to specify them in the ancestor layout
// if I delete this file, the configuration goes along with it – no more jumping around the codebase to "register"/"unregister" reachable routes
export const NavigationOptions = {
  title: 'My Route',
  headerLeft: <MenuIcon />,
};

[EvanBacon]

We originally used the static getNavOptions but decided against this because it would require loading the pages into memory to get the options. This would have no effect now, but it would block bundle splitting in the future. Instead, we implemented screen options where a navigator could manually mark the static configuration for the screens it planned to load. This is much closer to how web navigation works, where you style the elements in the parent.

The API is basically React Navigation but utilized in a more incremental way, you don't need the screen options, but you can add them if you want. Alternatively, screens can dynamically configure the layout from without a component by using the same API:

import { Tabs } from 'expo-router'

function Screen() {
  return (
    <>
      <Tabs.Screen options={{}} />
    </>
  )
}

[nandorojo]

So excited for this. @EvanBacon is crushing it 🔥🔥🔥

I'll comment by mentioning the one (and only) issue I've found to be hard to solve with file-based routing: infinite stack pushes within a given tab.

This issue is detailed (and solved) at nandorojo/solito#110 with component-based stacks.

Overview

If you're using Twitter or Instagram, you'll notice that you can continually push screens on top of each other without jumping from one tab to the next.

Click a tweet → the user → another tweet → another user, etc. In each instance, it stays within the same tab. Ideally, the URLs themselves for linking from one place to the next don't change. You're still just linking to /@user, then /tweet/:id.

The naive solution would be to create a separate link & duplicate screen for each tab: /home-tab/tweets/:id, messages-tab/tweets/:id. However, this is unfortunate because it duplicates code and leads to ugly, non-generalizable URLs.

I wanted to toss this out there to see if people have any ideas. My best thinking (currently) is to do the following:

1. use file system routing for your tabs
2. create a custom native stack with all of your screens
3. make the tabs all return the same stack
4. override useLinkTo, as show in How to reuse the same screen across tabs in a bottom tabs navigator? nandorojo/solito#110

This solution isn't great since it basically loses all the benefits of Expo Router. But it's a starting point. Curious to get any thoughts.

[EvanBacon]

Ya, perhaps a redirect or alias feature could be used to reuse a particular layout in multiple places. We currently implement all navigation context in the React Navigation state meaning if you reload a page or deep link directly into a page, you won't have that state anymore, causing a default behavior. This default behavior can be detected using navigation.canGoBack().

[nandorojo]

We currently implement all navigation context in the React Navigation state meaning if you reload a page or deep link directly into a page, you won't have that state anymore, causing a default behavior.

I think adding initialRouteName to the linking config should help this a bit, though. Stacks nested within tabs should typically define this in both linking config and in the <Stack.Navigator initialRouteName="index" /> component I believe. Unless I'm misunderstanding what you mean.

Ya, perhaps a redirect or alias feature could be used to reuse a particular layout in multiple places.

That would be really cool.

[danscan]

Assuming an app with a root tab layout, with a home and notifications tab, and common accounts and posts detail pages that should be reachable in either tab's stack:

app/

  # Root tabs layout
  (tabs)/
    home/
      _layout.tsx      # Home tab's stack layout
      index.tsx
    notifications/
      _layout.tsx.     # Notification tab's stack layout
      index.tsx

  # Common routes, reachable in either tab's stack
  accounts/
    index.tsx
  posts/
    index.tsx

Would it be possible to specify that the /accounts and /posts routes should be reachable in each tab's stack, by naming them as screens in the layout via their absolute paths, like so?

/app/(tabs)/home/_layout.tsx and /app/(tabs)/notifications/_layout.tsx (both have the same contents)

<Stack>
  <Stack.Screen name="/accounts" />
  <Stack.Screen name="/posts" />
</Stack>

[EvanBacon]

This is now mostly implemented using a new convention called Shared Routes. We now allow for conflicting route names when used inside Fragment Routes. To make the generation of reusable stacks easier to implement, we added the "clone syntax" where you can create copies of a directory using a fragment like (foo,bar) (syntax is subject to change). The name of the fragment is now more than cosmetic, if it matches a child route, that route will be the initialRouteName. Ideally, we'd also have some dynamic system for initialRouteName but this isn't very easy to add to React Navigation at the moment since it would require a waterfall of renders to build the entire navigation state.

[AndreBastos23]

Hey, just want to comment out that I love the work you're doing for react-native, together with the expo team and @nandorojo . You guys are one of the stronger forces into making react-native the premier implementation for mobile application.

One thing I'd like to suggest is that instead of using both (root) and root.tsx, couldn't we instead use the layout.tsx structure that nextjs is doing? Wouldn't they achieve the same thing?

[AndreBastos23]

Yeah that makes sense, still a bit unsure about the current API for layouts, since the navigator configurations and the routes themselves would live in different folders. I'll think about this and see if I can come up with something. I do think the current API is a bit confusing to developers who are accustomed to using react-navigation.

[EvanBacon]

In React Navigation, the standard format is to have a general screens folder and another navigation folder:

screens
  HomeScreen.js

navigation
  RootNavigator.js

This doesn't really abide by any particular navigator⇄screen structure or provide any visibility into the nested structure.

[kevinwolfcr]

+1 for adopting the new Next.js Layouts RFC. This can be useful for people wanting to colocate their screens + tests (and/or additional components) on the same folder.

[EvanBacon]

After trying Next 13 a bit for some side projects, I think the current colocation system will eventually be somewhat considered bad practice. It pretty quickly becomes difficult to distinguish between head.js, loading.js, body.js, page.js, api.js, footer.js -- which of these are convention vs colocation? which will become a convention in the future? This gets increasingly more confusing as the project scales and effectively requires a full understanding of every name for the given version of Next that you're looking at. I imagine the community will formulate some standard convention for files or directories that all of the colocated files will live in -- this is what I think we should do for Expo Router. Open to suggestions.

[marklawlor]

I agree that being unable to distinguish pages does seem like an antipattern. Currently SvelteKit uses the + prefix and Next.js used to use _ to determine convention vs colocation.

[Albert-Gao]

My current experience is, it feels better if the layout for route A sits within route A's folder...
Just way easier to look at,

for example, for the routes above, I have auth and non-auth
when we have more routes, this non-colocate structre would make it pretty hard to update a layout for a route,

it also aligns with the next.js layout RFC :)

[EvanBacon]

This doesn't really align with the Next.js RFC because the children would still need to be nested further. This assumption would also require a new file convention for indicating that the layout route file name doesn't map to any particular route.

[Albert-Gao]

https://nextjs.org/blog/layouts-rfc#regular-layouts

Am I missing reading something?

The layout.js is indeed in the router folder?

I get the point here, if put the layout.js inside of folder, we need to have a method to figure out the responsibility of each file, putting this outside would make it easier, it's a different trade-off, adding different extension like dashboard.layout.js would make this extendable.

[kevinwolfcr]

It would be nice if, instead of just importing expo-router/entry, it can be a component that can get conditionally rendered, in case I need to pre-fetch data, check if a user is authenticated, etc.

Something like this:

import { Router } from "expo-router"

export function App() {
  const [isAuthenticated, setIsAuthenticated] = useState<boolean | undefined>(undefined)
  
  useEffect(() => {
    // Do something here to check authentication
  })
  
  if (isAuthenticated === undefined) {
    return <SplashScreen />
  }
  
  return <Router initialRoute={isAuthenticated ? "/home" : "/auth" } />
}

[EvanBacon]

This is currently supported by having a top-level fragment layout:

app/
  (root)/
  (root).tsx # All requests go through this component.

[kevinwolfcr]

@EvanBacon thanks. How would you recommend to pass the initial route to the (root) layout?

[Albert-Gao]

I think you can embrace the file based nav pattern by creating fragments for cases like (auth) and (non-auth), and land on one of them, in their layout file, you can do the conditional re-navigate in this layout component, it almost works 😊

[coolsoftwaretyler]

Is there a reason that the routes need to use parenthesis? If I make a file at app/stack/index.js, I get an Unmatched Route error, but this works with app/(stack)/index.js.

This is maybe a minor nitpick, but the parentheses are very strange to me. When I read it in documentation, I assume it's a placeholder. I was trying to follow the quick start guide and got stuck for five minutes because I made two files:

• app/primary.js
• app/primary/index.js

I assumed the docs were telling me to name my stack and use that for the routes.

[nandorojo]

the parentheses indicate “fragments”, meaning they get ignored from the URL path. you don’t have to use them. but if you don’t, then their file names will be included in the URL path. so you would have to open /stack as a URL for your first case

[coolsoftwaretyler]

Thank you! Is there somewhere in the docs or a prerequisite reading that specifies that?

[nandorojo]

see layout routes: https://expo.github.io/router/docs/features/layout-routes

[mikeylemmon]

I've been doing some experiments integrating Expo with Remix and have an example monorepo running with Remix and an expo-router Expo app with component sharing between the two — https://github.com/mikeylemmon/remix-rnw/tree/monorepo-expo-router. Based on my experience so far, I posted this to a discussion on the remix repo, but I think at the moment it's probably more relevant for discussion here:

remix-run/remix#1578 (reply in thread)

Intuitively I'd like to have unified fs-based-routing between expo and remix so that the DX feels like it does with expo-web, where platform-specific divergences can be managed solely through file extensions (*.native.*, *.web.*, etc.) and platform detection. This isn't immediately possible unfortunately, as expo-router is going for more Next-ish filename conventions, meaning parallel filesystem route trees need to be built for both expo and remix, even if the file contents are identical aside from the root layouts (as they are in my example). User-configurable matchers in expo-router could enable a very light-weight solution to this [update: limited testing with a locally-modded expo-router suggests this would work], but short of that another option could be to use remix.config's routes function to dynamically crawl an expo-style route tree into remix.

@EvanBacon is there any chance of getting some hooks into the API to be able to override the matchers? If you're amenable in theory and have an idea for how you'd like it to work then I'd be happy to attempt an implementation. Or do you have any other suggestions for how unified expo/remix fs-routing could be achieved? Regardless, thanks so much for your work on this, it's a massive upgrade to building Expo apps!

[EvanBacon]

In my opinion, we currently don't have enough data to create a meaningful rewrites API. When we do, it'll probably look like a basic function in the beginning of getStateFromPath which rewrites the paths before parsing them into state.

Edit: just read through your findings, looks really nice so far. Good work!

[mikeylemmon]

@EvanBacon you mentioned below that "There are no plans to add low-level, generalized abstractions to support web-only frameworks," and I'm just curious how that comment relates to the possibility of a rewrites API that you mentioned here — is something along these lines still potentially in the cards? As I elaborated above, it feels to me that some sort of API hook in this area would dramatically improve the ability of the developers of "solito or related abstractions" to create a harmonious DX between Expo and the web-only frameworks/toolchains targeted by the abstractions.

I really like the opinionated take on filesystem routing that this project is pursuing, but it also exists in an ecosystem filled with other highly-opinionated projects, and among them Expo is unique in that developers are far more likely to want to integrate Expo with their web-only framework of choice compared to devs trying to integrate two different web-only frameworks — cross-compatibility matters way more for Expo than it does for web-only frameworks because projects that use Expo are by far the most likely to have a need/desire for cross-compatibility in the routing domain.

The DX for Expo web is great, but Expo web is not viable as, or even designed to be, a Next/Remix/etc replacement except in very limited use cases. Providing a hook for abstraction developers to create a routing compatibility layer between Expo and web-only frameworks would enable us to extend that great Expo-web DX into a wide array of use cases where it is currently unavailable.

I continue to be super grateful for your work, and I understand that the problem space you are tackling here is filled with complexity, trade-offs, and competing interests — thanks for considering my points, and regardless of the outcome I'll continue to be appreciative of the time you and the Expo team are putting into making Expo such a great development platform.

[EvanBacon]

Adding a rewrites API makes sense to me for versioning and refactoring purposes. It's a bit awkward to build right now because it needs to be executed in application code on native and server code for web routing.

Re: Expo web: #1 (reply in thread)

[redbar0n]

@EvanBacon Do you have enough data now for a file system route matcher rewrites API? Such an API would be very helpful, since people could make Expo Router align with other file system routing patterns they employ (to avoid having a monorepo with multiple app directory structures).

[redbar0n]

@mikeylemmon You may be interested in this, a first draft of doing the same you’re attempting with Remix, but with TanStack Router instead. Namely, align it with Expo’s file system routing conventions: TanStack/router#207 (reply in thread)

[brillout]

Author of vite-plugin-ssr here.

The most important part of the API is the routes convention as this cannot easily change after it's been locked in.

This essentially tightly locks Expo Router with Next.js.

I wonder whether it's a deliberate choice to marry Expo Router with Next.js forever.

Or is there a plan to make Expo Router work with other frameworks?

If Expo Router wants to support other frameworks, then it should have a flexible core with a JS API that accepts a function route => root component. I.e. it's the framework which takes care of doing the routing while providing the routing information to Expo Router. That way, Expo Router can adapt to any framework. Thoughts?

[codinsonn]

Personally a huge fan of route No. 2, where Expo provides first-in-class providers for e.g. Next.js / Remix.run and other frameworks that are fully focused on the web, so that Expo's main efforts can continue to focus on mobile and, ideally, closing some gaps between web & mobile API's

[EvanBacon]

@redbar0n these paths don't describe mutually exclusive options. Use expo web or don't, it will still exist regardless. If you want to mix Expo with a different framework, you can do this in a monorepo -- it's been possible since day one -- ref: Solito.

[EvanBacon]

@codinsonn interesting idea. However, the lines Expo provides first-in-class providers for [...] frameworks that are fully focused on the web and so that Expo's main efforts can continue to focus on mobile are diametrically opposed. Do we maintain first-class web support for other frameworks, or focus on mobile?

Maintaining even one first-class framework adapter is a full-time job and would require a developer's full attention for updating whenever the framework updates. For example, the Expo + Next.js adapter had more open issues than any other official Expo dev tool (including Expo CLI) when it lived in the Expo CLI repo.

Perhaps it would make more sense for the Remix and Vercel teams to add first-class support for Expo since they have substantially more resources and larger teams of developers. If the community would also like to build and maintain adapters like Solito they can do that as well.

[codinsonn]

@EvanBacon Makes sense. I've been pondering whether I could take some of this work on myself, but I'm more in @nandorojo's camp of maintaining a project like Solito instead. Reading here that it would take a full-time job to maintain, I can also sadly say that it's not in the cards for me at the moment.

I have mentioned on events / livestreams / Q&A's by the Vercel team that maintaining an adapter for expo on their end might be a good idea, but every time the answer was "We're really focused on web first".

[redbar0n]

@EvanBacon With "Closed" I was referring to your stance that "Expo is the framework for universal React Native and not an adapter for other frameworks." Not being or maintaining an adapter is ok, but why not expose some core functions so that others are enabled to create adapters?

A monorepo doesn't really solve the problem, which @brillout mentioned:

If Expo Router wants to support other frameworks, then it should have a flexible core with a JS API that accepts a function route => root component. I.e. it's the framework which takes care of doing the routing while providing the routing information to Expo Router.

Solito doesn't let you do this. It isn't able to pass a route function to Expo, because Expo doesn't have such an API.

Expo could still avoid building adapters for every framework, since exposing an API for taking in routing info to Expo Router enables framework authors to make the adapters themselves.

That way, frameworks that seek to unify URL's with routing across platforms could use any more web-compatible router they want, and potentially even a Single Route File instead of filesystem routing, if they want. That's what I mean with taking the "Open" path.

[VirusTermico]

Firstly congrats to expo team for bring that "expo router". I didn´t give a deep look in expo route doc, i don´t know if you already cover this.
I am concern about use explicit path in url when it´s use un expo web insteade just have the common localhost:19000 for example display the path /home or /products/id

[jamonholmgren]

Just finished recording a React Native Radio episode with you, @EvanBacon, about this, and I'm really loving what you're doing.

I do want to open a further discussion about using the ./app folder and allowing it to be configurable. We maintain Ignite, which is the most popular third-party React Native & Expo boilerplate. We have a pretty large user base that relies on the conventions we've established there, and the structure looks something like this:

app
  components
  config
  i18n
  models
  navigators
  screens
  services
  theme
  utils
  app.tsx

This structure has been in place for many versions and our CLI tooling, documentation, and much more is built around it.

I would like to try implementing Expo Router with Ignite, but this presents a fairly significant effort. Additionally, I have qualms about having everything (non-co-located) be in the root (such as app/models, app/config). To me, those belong in the app folder.

If we could configure the root of Expo Router to be something like app/routes or repurpose app/screens, that would solve our issue, make the transition much easier, and make more sense within the patterns and paradigms we've already established over the years. While we could go through the effort of reshuffling everything around, it's not a simple change and not something I'd want to do lightly, if there's another way.

Thoughts & discussion welcome!

[EvanBacon]

Based on the folder structure provided, it won't be as simple as renaming the directory from app to app/screens:

app
  components <- Pending a convention for co-location in the `app` directory.
  config
  i18n
  models
  navigators <- rolled into the routes and fragmented across the structure
  screens <- presumably these don't follow the Expo Router file convention, they'll need to be refactored regardless.
  services
  theme
  utils
  app.tsx <- This file would become either `./index.js` (required by React Native code loading) or `app/_layout.js`.

Given the vast amount of refactoring required to match the routing convention (specifically regarding fragments), shifting everything else down one level would seem relatively simple.

instantiate expo router rather than using the default import 'expo-router/entry'.

I would advise against using a directory nested inside of app, or changing the directory at all. The require.context must be defined at runtime (for Metro resolution) which is why it is available at all (i.e. was not added for customization).

Here are a number of existing things that will be invalidated (from a repo search):

• All docs and examples (which indicate app/), including doc blocks.
• bootstrapping screen
• Migration error message

There are probably a number of other assumptions around the directory existing one level under the package.json. Further, when we add pre-rendering there will be a Node.js API added to expo start and expo export which would also need to be configured to determine the root directory in order to identify and statically render each route.

Any project which changes the root directory at this very early stage will be doing so at the risk of the project not behaving as expected.

[jamonholmgren]

@EvanBacon Unfortunately, that's putting us in a bit of an awkward position with adopting Expo Router within Ignite. I'll discuss, but given the large userbase we have and tooling built around assumptions with how Ignite's folder structure is built, reworking the folder structure isn't something we would prefer to do unless we really need to. I guess I should have chimed in earlier in the process when this part of the RFC was still open for feedback.

[jamonholmgren]

Basically, we have almost 7 years of work built around having our code located in ./app -- having a new convention force us to move it feels a little like Expo didn't consider Ignite at all when designing this, which is odd given how many people use it in the RN community.

[frankcalise]

Based on the folder structure provided, it won't be as simple as renaming the directory from app to app/screens:

@EvanBacon, you are correct in those would require some refactoring. I went ahead and started an expo-router approach to an existing Ignite app and landed on your same suggestions

With the context change (I realize it was not intended for this use, but if the POC helps)

1. ./app/app.tsx -> ./app/routes/_layout.ts
2. ./app/screens/ + ./app/navigators/ -> ./app/routes/
3. ./app/components - left alone as these are generic Button, Toggle, Icon, Card etc used across all screens/more screen specific components (which would be more co-located near the layout itself like you mentioned

You can see progress here (although I haven't completed all screens/navigators to routes yet, I will try and get it cleaned up): https://github.com/infinitered/ChainReactApp2023/tree/feat/expo-router/app

[frankcalise]

Given the vast amount of refactoring required to match the routing convention (specifically regarding fragments), shifting everything else down one level would seem relatively simple.

@EvanBacon what did you mean by shift everything down here if app\sub\directories are all routes? Do you mean a structure like

app\routes\here
src\components
src\i18n
etc..
?

[kylerjensen]

So excited for this @EvanBacon! I think Expo Router could really help speed up development and could be a great improvement over the currently available navigation frameworks.

One major benefit I see of Expo Router is that it seems to really get "out of the way" and let's developers focus on writing their application code rather than spending time writing code specific to the navigation framework. On that premise, I'd like to suggest a change to the way Expo Router handles passing parameters between screens. In React Navigation, (and Expo Router), params are passed via a route.params object in the component props. I don't like this pattern because it tightly couples my components to the navigation framework I'm using, and it makes components more difficult to test. This has been a pet peeve of mine with React Navigation and I'm sad to see that it was carried into Expo Router.

In the interest of "getting out of the way", I'd propose removing these extra layers and translating route params and path variables directly into React props. Things like the navigation utility object and other routing metadata could be accessed via a React hook instead of props.

The way I see it, this approach would accomplish four things:

1. Allow developers to focus on writing components that are highly testable and independent of the navigation framework
2. Make it a little easier for developers to define and use types for their component props in the same file as the component itself
3. Make route parameters a little easier to consume
4. Reduce Expo Router's dependency on React Navigation

Example:

import { useEffect } from "react";
import { View, Text } from "react-native";

+ export type HomeProps = {
+    post: Post
+ };

- export default function Home({ navigation, route }) {
+ export default function Home({ post }: HomeProps) {
  useEffect(() => {
-     if (route.params?.post) {
-     // Post updated, do something with `route.params.post`
+     if (post)
+     // Post updated, do something with `post`
      // For example, send the post to the server
    }
-  }, [route.params?.post]);
+  }, [post]);

  return (
    <View style={{ flex: 1, alignItems: "center", justifyContent: "center" }}>
      <Text>Home Screen</Text>
      <Link
        href={{
          pathname: "details",
          // /* 1. Navigate to the details route with query params */
          query: { itemId: 86, otherParam: "anything you want here" },
        }}
      >
        Go to Details
      </Link>
    </View>
  );
}

[EvanBacon]

I'm sad to see that it was carried into Expo Router.

Everything from React Navigation was carried over into Expo Router as the framework is built on top of React Navigation, we're effectively the same team.

The route and navigation props are already being deprecated in favor of the hooks in upstream React Navigation. Similarly, Expo Router will recommend the use of hooks such as useHref to access query parameters instead of props.

Passing directly as props

An earlier version did this but we moved away for the following reasons:

• Conflicts with React: what if a query parameter is named children or key?
• Removes the ability to determine if no props exist. Currently you can check params == null but you won't be able to do that with React props.

[marklawlor]

components <- Pending a convention for co-location in the app directory.

I'm interested in discussing this more. After using Sveltekit and Next 13, I found that I've enjoyed using only folders to define routes. Additionally, I've been looking into generating Typing solutions for Expo Router and from the different approaches I've researched I think Sveltekit's (using multiple rootDirs and generated types) is the simplest to implement and maintain - but again relies on routes only being defined via folders.

[EvanBacon]

Two things I'm thinking about:

1. Adding a file convention (_page, _app, etc) which when defined, turns the directory into a route and potentially disables using files from that point down. If someone wants a more directory-driven experience, they could just ensure to use this convention somewhere lower in the hierarchy.
2. A system for ignoring directories in the matcher. This seems like something we'd want regardless of which option is used.

I personally don't think the Next 13 colocation pattern is perfect as-is and probably needs something extra to preserve comprehension at scale. More info on this opinion.

[marklawlor]

1. I think strict rules work better. I think it should either be file or directory based.
2. What if there was a convention for ignored directories where colocated files could live? _internal/_private/_app. These could be at any level and are simply ignored from routes.

[EvanBacon]

I'm leaning toward what you described in 2. as it seems the least disruptive. The option in 1. will probably allow some strict rule but it's more aimed at the eventual lazy loading system, where things like the error boundary will probably be split into an _error or _catch file. We'll want users to be able to incrementally adopt this new system when we're ready to implement it on the EAS/expo-updates side.

[marklawlor]

As Type Safety becomes more popular, I think we need to consider what approach Expo will take to generate typings for routes.

Currently there are not many solutions that provide typing for file based routing, so there is room to experiment.

The most feature rich is Sveltekit which provides types from ./$types. $types.d.ts is a generated file that lives in .sveltekit/types/**/* a hidden shadow directory that follows the same structure as your routes. Typescript is able to locate this file due to rootDirs in the tsconfig.json.

import { PageLoad } from "./$types"

export function load({ params }) {
 // ...
} satisfies PageLoad

We could adopt a similar method for Expo Router

// [id].ts
import { Page } from "./[id].types" <-- What should this be called?

export default function Page({ route }) {
 // ...
} satisfies Page

I've also tested using Typescript plugins (which Next 13 is using), but lack of type-checking during tsc is a bit annoying.

[alyiev]

When first release?

[fungilation]

I see rc1 just dropped. Any breaking changes from last 0.0.45?

[EvanBacon]

I can add a formal changelog, but no (unless I missed something).

[fungilation]

Not with rc3 now either? A change log noting actual breaking changes would be appreciated if there's any 😉

[cseelus]

@EvanBacon Yes, a changelog would be highly appreciated.

[MaxRobertsDear]

Loving this! Have successfully been playing with it locally (thanks for the example projects).

Facing difficulties with the project building in EAS. Seems related to editing the main entry of the package.json.

Project setup is a fresh expo managed workflow project. Haven't done anything other than follow the steps for adding expo/router, followed by the command eas build --platform ios --profile simulator (and yes, it successfully builds on EAS once I change the entry point in package.json back to default). This might be EAS's lack of support for custom entry points rather than the expo/router library. And it does seem that your import "expo-router/entry"; in the index.js file follows the suggestion for a custom entry point. Just thought it was worth mentioning because it would be great to see this navigation paradigm into as many projects as possible and it seems there's still a little friction 😁.

error: File /Users/expo/workingdir/build/ios/build/Build/Products/Release-iphonesimulator/MyAppName.app/main.jsbundle does not exist.

[MaxRobertsDear]

so, turns out you already have the solution in your example project - it's the metro.config.js that needed adding. Worth adding to the installation steps when you get around to it.

Really excited for this project!

[EvanBacon]

Just fyi, but technically EAS and Expo both support custom entry points but we can't confidently support development builds that don't use expo-dev-client as the /index.bundle path is hardcoded into the default React Native code loading. Worth fixing by making expo-dev-client smaller and adding by default in all projects.

[monochrome-yeh]

I'm annoyed of this design, if you were using storybook to manage your component (a pure component library ), but the file-base system enforce you to put those components into /app root? why? the /app root in my opinion is a application layer to combine your component with your business logic, however, whenever you want to set a pure component into Stack.Screen, you have to move those components into app/ folder? otherwise you cannot address to correct path ???????

[danscan]

Just import the components you want in your screen from where ever they already are. For example, you can have both app/ (routes) and src/ (the rest of your app's APIs, components, etc. which you can import into app).

[rieger-jared]

I'm with @monochrome-yeh on this point. I think for a lot devs src is the conical location for all code that results in the actual product. It makes it easy to visualise project tree and filter out the build and other config files that don't affect business logic.

Can we please at least make this configurable? I'd like to move index.js and app to a root src dir.

[sraut1]

@EvanBacon Great work on Expo Router. I am using Branch deeplink URL's. I configured the app but after clicking on branch Universal deeplink I get Unmatched route which is correct because deeplink is masked with random string and which is not a valid file component in route hierarchy. I am able to intercept the incoming URL to decode it and read the data, however I dont know how to stop Expo router from navigating itself and let app handle the routing manually based on data passed in branch URL. Appreciate your help

[frlnnvd]

[marklawlor]

It's best to simply redirect the user to a different URL instead of conditionally rendering screen. We have a detailed example in the Authentication guide https://docs.expo.dev/router/reference/authentication/ which shows how to protect routes until a user has logged in.