// app/(tabs)/_layout.tsx
import { Tabs } from 'expo-router';
export default function TabLayout() {
return (
<Tabs screenOptions={{ tabBarActiveTintColor: 'blue' }}>
<Tabs.Screen
name="index"
options={{
title: 'Home',
tabBarIcon: ({ color }) => <HomeIcon color={color} />,
}}
/>
<Tabs.Screen
name="settings"
options={{
title: 'Settings',
}}
/>
</Tabs>
);
}Recunosc, la început am fost sceptic. Folosesc React Navigation de pe vremea când era în beta și m-am obișnuit cu stilul ăla imperativ unde declari totul manual într-un singur fișier gigant. Dar la un proiect recent, un marketplace cu vreo 18 ecrane, am decis să dau o șansă noului Expo Router (v3). Mi-am dorit să văd dacă promisiunea aia cu „file-based routing ca în Next.js” chiar ține la tăvăleală pe mobile.
Marea diferență nu e doar că muți rutele în fișiere, ci cum gândești structura de directoare. Dacă vii din React Native pur, o să ți se pară ciudat la început că numele folderului îți dictează URL-ul de deep link, dar după ce te obișnuiești, e greu să te mai întorci.
De ce să te complici cu migrarea?
Principalul motiv pentru care am făcut switch-ul a fost deep linking-ul. La React Navigation, de fiecare dată când adăugam un ecran nou, trebuia să actualizez manual configurația de linking și să am grijă la ierarhie. Era o sursă constantă de bug-uri. Cu Expo Router, am economisit cam 30% din timpul de setup pentru rutele noi. Creezi fișierul, pui un export default și gata, ai ruta mapată automat.
Dar am dat și de un trade-off sincer: file system routing-ul este mult mai restrictiv. Nu poți să muți un fișier de colo-colo fără să strici toate link-urile din aplicație. În plus, dacă ai o logică foarte complexă de autentificare unde vrei să schimbi radical stack-ul în funcție de rolul userului, Expo Router te forțează să folosești grupuri de rute (cele cu paranteze rotunde). E curat, dar necesită o planificare mai riguroasă a folderelor de la început.
Cum configurezi tab-uri și stack-uri nested
Aici e locul unde majoritatea ne blocăm. Schema e simplă: folosești grupuri. Am avut cazul ăsta: un tab bar jos, iar în primul tab (Home) aveam nevoie de un stack pentru detalii produs, dar voiam ca ecranul de detalii să ascundă tab-urile (să fie full screen).
Structura de fișiere care mi-a salvat sănătatea mintală a fost:
app/(tabs)/_layout.tsx(aici definești Tab.Navigator)app/(tabs)/home.tsx(ecranul principal)app/details/[id].tsx(ecranul de detalii, scos în afara folderului de tabs ca să fie full screen)
Folosind (tabs) cu paranteze, îi spui routerului că folderul respectiv e doar pentru organizare logică și nu apare în URL-ul de deep link. E o soluție elegantă care elimină mult cod repetitiv pe care îl scriam înainte în NavigationContainer.
Performanță și tipizare
La capitolul Typescript, Expo Router generează automat tipurile pentru rute. Am pățit de câteva ori să nu se actualizeze imediat, dar un npx expo customize tsconfig rezolvă de obicei problema. Ca performanță, n-am simțit nicio diferență sesizabilă în runtime, dar build-ul local durează cu vreo 10 secunde mai mult pentru că trebuie să indexeze tot sistemul de fișiere.
E important de reținut: Expo Router câștigă detașat dacă ai nevoie de web parity sau SEO. Dacă faci o aplicație „mobile only” foarte simplă, React Navigation rămâne „the safe bet” pentru că ai control total și zero „magie” sub capotă.
Voi ce folosiți la proiectele noi? Vă place ideea de file-based routing în mobile sau vi se pare că adaugă prea multă abstracție inutilă?