Brent Vatne Yeah I know, I just thought it would be nice to have that feature build in too expo-router rather than dropping it and using react navigation. 🙂

Joost - what features from expo-router would you miss if you switched to react-navigation? most of the differences are accounted for by the file system API and the features that are made possible from that (eg: automatic deep linking support)

Brent Vatne I think the idea is something like Next JS App Router offers, where you can use an "escape hatch" key on a subfolder (say, _components) to co-locate files relevant to only that route within the router, without being included in actual routing logic.

Granted there is a bit more to the Next.js model (in that you can also co-locate any file not using a reserved name like layout/page/error etc) but the broad idea is allowing "escaped" folder names or file names to treat each route as a feature branch with routing information rather than emulating a routing file, just via a specific folder heirarchy. It's like an evolution of file based routing, if anything.

Next JS made this move based on very similar feedback to Pages router, which was laid out much like expo router is now (routing files only' all other exclusive files need to either be in some monolithic components folder or organized into a mirrored domain model that requires duplicating the entire app folder structure twice)

I think Next JS has proven this approach to be highly preferable for many teams, leading to more clarity about where components live and are used from folder structure alone, without the overhead of managing two separate folder heirarchies.