Expo Router v2+ #309
Replies: 10 comments 17 replies
-
Looking forward to v2 and onwards! Really looking forward to the testing documentation. I would argue against the customisation of the Root directory ( |
Beta Was this translation helpful? Give feedback.
-
Looking forward to having https://17.reactjs.org/docs/concurrent-mode-suspense.html#approach-3-render-as-you-fetch-using-suspense capabilities. It would encourage developers to deliver a better experience for their users with both literal (parallel execution of fetching and rendering) and perceived (useTransition, useDeferredValue) improved async load times, and solve a complete family of problems regarding trying to pass non-serialisable async-related goods with navigation (which the router would directly provide in the route component's props). |
Beta Was this translation helpful? Give feedback.
-
Another thing that is missing is the ability to opt out files from creating a route. I think using something like an underscore The latest Next.js 13.3 version adds support for this in their new router:
|
Beta Was this translation helpful? Give feedback.
-
Currently everything inside app is route and there is no way to have all route related things in one place. Coming from Nextjs world, I would love to have all my hooks, redux slices etc in one place. |
Beta Was this translation helpful? Give feedback.
-
I am waiting for
|
Beta Was this translation helpful? Give feedback.
-
Is it possible to partner with Vercel and mirror the Next.js patterns as much as possible, then use Next.js as the web version, similar to what Solito is doing? Maybe Expo Router v2 and Next.js v14 release simultaneously with an insanely nice DX for RNW devs? 😏 |
Beta Was this translation helpful? Give feedback.
-
Hello, and thanks to the Expo team for the great work they have accomplished. Can Expo Router be used for production apps already or should we stick to React Navigation until it reaches a more mature stage? |
Beta Was this translation helpful? Give feedback.
-
No idea how to test navigation implemented by expo-router. This should be documented. |
Beta Was this translation helpful? Give feedback.
-
Any chance to have a functionality similar to |
Beta Was this translation helpful? Give feedback.
-
Is there a reason expo has decided against generally supporting bundle splitting via dynamic imports, which is the preferred way according to official docs and is the backbone for React.lazy and standard libraries such as @loadable/components? The benefits of bundle splitting go further than just startup time / navigation. For example, our app's js bundle is now over 10MB. That makes for a huge OTA download. If the bundle splitting that is already in place for our react-native-web website had 'just worked', small bug fix OTAs could be fully downloaded and ready with only 100s of kilobytes of bandwidth, something more realistic to be finished in time on app startup, rather than falling back to background updates. |
Beta Was this translation helpful? Give feedback.
-
Ideas
Here's an outline for features that we can add to v2 and beyond of Expo Router. The list is not final and many features will be pushed to a later version to promote quicker iteration. This doc is primarily designed to help Expo Router users understand why certain features which seem critical may be blocked on other, seemingly unrelated, features which we're actively working on.
React Navigation
In React Navigation v7 a number of concepts from Expo Router like Link
href
and static configuration have been upstreamed, this helps keep improve the ability to drop down from Expo Router when required functionality is not yet available.We should aim to stay close to the latest version of React Navigation when possible. Most navigation-related improvements will depend on React Navigation changes:
#
)UI Primitives
The existing primitives provided by React Navigation are good for native but provide very limited support for wider screens and mobile web. While the UI layer is of lesser importance than the overall router, there are somethings that would generally improve the overall quality of apps built with Expo Router:
Documentation
The following concepts should be documented:
Async Routes
Expo Router should automatically lazy load routes and bundle split pages, this can be done using React Suspense and a number of other bundler modifications. We're currently working with the maintainer of Metro, @motiz88, to add/expose the requisite upstream functionality.
Metro will include two types of React Suspense; development and production. Development suspense is used for faster startup time and better debugging as screens will only throw errors after they're loaded. This technique is used internally at Meta for the Facebook app and drastically improves the developer experience at scale.
Production suspense will be used to implement bundle splitting, which is especially important for improving web support.
Both forms will improve our ability to add standardized data fetching in the future.
Styling
Expo Router is first and foremost a bundler project. Adding styling features that modern web developers have come to expect will require a number of bundler improvements.
The specific configuration used for Expo Router includes a custom Metro runtime, this runtime should be extended to support a number of universal styling options, namely:
Fonts
Traditionally, React Navigation projects would
return null
at the root while pending the fonts loading, this paradigm breaks navigation hydration and needs to go.We need to improve how fonts work in upstream React Native/Expo so the default behavior is more closely related to web's "fallback" font-display style. If devs want to ensure the first native frame has loaded fonts, then they should keep the splash screen open over the UI as it loads in the background. @motiz88 has already great work on this by suppressing loading errors in upstream React Native.
Also worth noting that fonts generally load instantly in production because Expo fetches/caches fonts offline for improved startup performance.
Configuration
Most Expo Router is executed in runtime-space, meaning customizations will more than likely require improved environment variable support. This will enable us to modify the runtime-behavior based on developer/CLI settings.
Below are the current customizations worth investigating:
app/
directory): this feature would exist for convenience and add no technical benefits or features for the end-user. Regardless, the feature is highly requested so it'll be added sometime after more critical functionality has been resolved.window.location
on web, this would improve the ability to data fetch universally, e.g.fetch('/data')
rather thanfetch('https://acme.com/data')
.Customizations will increase conventional complexity a lot and be very difficult to thoroughly test continuously. Some customizations will be considered advanced functionality and generally discouraged for most projects.
Universal Linking
Universal linking is critical for app discovery and I'd love to make this as automated as possible. We currently have a guide for universal linking but it could be much simpler by introducing tooling like automatic apple-app-site-association generation. Android support can also be improved by generally dropping the requirement for React Navigation URL prefixes.
Web
Most modern web-only frameworks utilize a filesystem convention to create various static optimizations. Now that we have native file-based routing, we are finally unblocked to improve web support. Traditionally Expo for web has just been a general fork of Create React App with many inconsistencies between web and native.
Expo Router aims to be fully universal. All technical decisions are made with both web and native in mind. The first milestone is getting our "Metro for web" functionality to be a reasonable replacement for the current Webpack implementation so we can minimize divergence between platforms.
Thanks for Reading
If you'd like to support the project, please try it and provide feedback. Feel free to contribute ideas in this discussion. As mentioned at the top, many of these features will be implemented in later versions of Expo Router as needed to ensure we're releasing smaller changes more frequently.
We're aiming to solidify Expo Router as much as possible then roll it into the default Expo offering. This would include merging the Expo Router docs into the Expo docs, moving the code to expo/expo, setting up the router by default in projects, and generally optimizing the Expo SDK to work better with conventions like React Error Boundaries.
Write Once, Run Everywhere is quickly becoming a reality and we're excited to push it as far it can go!
Beta Was this translation helpful? Give feedback.
All reactions