React Navigation VS Expo Router V2
Imagine being in a maze. At one corner, you have a path you've walked on countless times. You know its ins and outs, its twists and turns. On the other corner, you have a new path. It's slick, shiny, and promises the future but it's not fully adopted yet. This, my friends, is the dilemma of every React Native developer when it comes to picking between React Navigation and Expo Router V2.
The million-dollar question indeed: Is the V2 version of Expo Router stable enough to make the switch?
My Point of View
As a junior developer who has tiptoed around React Navigation in past projects and now experimenting with Expo Router V2 for my new Saleor Dashboard app project, I believe I'm in a good position to weigh in on this. To keep things neat and comprehensible, let's dive into each navigation method one at a time.
React Navigation: Tried and True
React Navigation is like that trusty old hammer in your toolbox. It's a feature-packed solution that has stood the test of time. But like every tool, it has its limitations. When you deal with a multitude of directories, routes, and layout options, things might not always be as smooth as you'd want.
The Future: Expo Router V2
Now, let's put on our futuristic sunglasses and talk about Expo Router V2. Its claim to fame is its file-based routing system, just like Next.js has.
Here is a brief rundown of its features:
Native: It's built on top of React Navigation suite, making it optimized by default.
Shareable: Every screen in your app is automatically deep linkable.
Offline-first: Apps run offline-first, updating only when you publish a new version.
Optimized: Routes are automatically optimized with lazy evaluation in production.
Iteration: It supports Universal Fast Refresh across platforms.
Universal: A unified navigation structure across iOS, Android, and the web.
Discoverable: Your app content can be indexed by search engines.
Sounds amazing, right? But let's not jump to conclusions yet. It's storytime again!
My Adventure With Expo Router V2
For my e-commerce project, I had to manage an intricate navigation structure with numerous screens. Creating a new product, editing an existing one, showing product details, calculating profit margins, and many other operations. Expo Router V2 handled most of these beautifully. However, at times, it showed me some serious abnormalities.
Nesting Layouts: Stack to Tabs to Stack
Here's the project structure I started with:
/app
: This is the main directory for Expo Router./app/_layout.tsx:
This root layout contains the providers and a stack navigator./app/index.tsx
: This houses the authentication screen that utilizes a stack navigator./app/(tabs)/_layout.tsx
: Here, I've arranged a tab navigator containing home, orders, products, and profile screens folders.(tabs)/products/_layout.tsx
: This directory contains a stack navigator for the screens related to products.(tabs)/products/index.js
: This is the main products listing screen.
For a smooth product creation and editing workflow, it was important to have a way to show a summary of the product data, say pricing for instance, and then have a CTA button or pressable text to redirect the user to a corresponding detailed screen to have more control over that particular data, like calculating margin and profit.
/product/[id].tsx
: This dynamic route serves as a specific product screen, showcasing its details and providing edit functionality./product/CreateProduct.tsx
: This is the main screen for creating a new product./product/Pricing.tsx
: This, among other detailed screens like inventory, provides granular control over a product's data.
The idea was for these screens to function as stack screens, as per the _layout.tsx
within the products folder. However, they manifested as icon-less tabs. Attempting to click these mysterious tabs resulted in errors. Even the Stack to Tab to Stack navigation strategy with an additional layout file within the product
directory didn’t rectify the issue.
To address this, I moved the product folder to the root, alongside the (tabs)
group folder. This change allowed screens like CreateProduct
, the dynamic route for editing an existing product, and the detailed screens to inherit a stack navigator from the root layout. This is far from acceptable since it defeats the purpose of keeping related things together in the project structure.
Pay Attention to the _layout.tsx
File
One crucial observation from my journey with Expo Router V2 pertains to the _layout.tsx
file. When setting the path name in the Stack.Screen
, these details are key:
If the screen resides in the same folder as the layout, only the screen's name is needed. If it's the root screen of the folder,
index
should be the value of the name property.If the
index
screen is nested within another folder and that route lacks a layout file,folderName/index
should be the value.If the
index
screen is nested within another folder with a defined layout file, only thefolderName
should be used. Theindex
screen will automatically get picked up.
This isn't documented and can be a source of frustration. As the syntax varies based on changes, missing routes can lead to errors, prompting developers to retrace their steps.
A Curious Interaction
In the context of project structure, I used Redux solely for managing local data. To maintain related entities close together, I placed store.js
in src,
the products
and product
slices in the products
folder.
However, I kept receiving an error indicating the product
slice wasn't being picked up by the store, even though both slices were in the same location.
These abnormalities sometimes force me to make decisions that may not adhere to the best practices of the project structure. As a workaround, I created a slices
folder in the root of the app
folder, and I put both slices in it, which instantly resolved the issue.
Takeaways
To conclude, Expo Router V2 may not be a bed of roses. It has its bugs and quirks, but it also has the potential to change how we navigate in our apps.
My advice to fellow developers? If you're already learning React Navigation, stick to it. Expo Router V2 is, after all, based on it. However, if you're starting fresh, feel free to dive into Expo Router V2. It's the future, and what's development without staying ahead of the curve?
On a cautionary note, if you're building projects that you care about deeply, and you don't like surprise bugs popping up, I suggest holding off on switching until the community gives the green signal.
Route safely!
NBR0KN
Subscribe to my newsletter
Read articles from NBR0KN directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
NBR0KN
NBR0KN
OPEN FOR WORK. Hey there, i am Abderrahim, a passionate React Native & Expo developer, specializing in creating captivating mobile applications for exceptional user experiences. My knowledge encompasses JavaScript, React, React Native with Expo, TypeScript, Redux, GraphQL with Apollo Client, and cloud services like AWS and Firebase. I adapt swiftly to meet the specific needs of any project.