import { Stack } from 'expo-router';
export default function FeedLayout() {
return (
<Stack
screenOptions={{
headerStyle: { backgroundColor: '#111827' },
headerTintColor: '#fff',
headerTitleStyle: { fontWeight: 'bold' },
}}
>
<Stack.Screen
name="index"
options={{ title: 'Feed Principal' }}
/>
<Stack.Screen
name="[id]"
options={{ title: 'Detalii Postare', presentation: 'card' }}
/>
</Stack>
);
}Am refăcut recent navigația la o aplicație de mobil cu peste 12k active users lunar și am decis să trecem de la clasicul React Navigation la Expo Router. Se vorbește mult despre file-based routing în React Native, dar tranziția vine cu câteva capcane serioase dacă ai structuri mai complexe. Aici e experiența mea din producție și cum configurezi corect un setup de Tab-uri cu Stack-uri nested fără să-ți prinzi urechile.
Când merită să migrezi și când să zici pass
React Navigation e un standard de mulți ani. E imperativ, e predictibil, dar devine un maelstrom de boilerplate la aplicații medii spre mari. Sincer, dacă ai deja o aplicație veche pe React Navigation, în bare workflow sau netrecută pe Expo SDK recent, nu merită efortul de refactoring doar ca să fii la modă. Am pierdut vreo 3 zile doar curățând typings-urile de TypeScript pentru rute la o migrare anterioară pe un cod legacy.
În schimb, dacă ești deja pe Expo SDK 49+ sau începi un proiect nou, Expo Router e un no-brainer. Deep linking-ul funcționează out-of-the-box, chestie care la React Navigation clasic e un nightmare de configurat cu URL schemes și prefixes. În plus, am scăzut lejer cu 35% cantitatea de cod dedicată strict navigației.
Setup-ul de Tab-uri cu Stack nested (unde se încurcă lumea)
Cea mai mare confuzie la file-based routing apare când vrei un Tab Bar jos (de exemplu Feed și Profile), dar pe tab-ul de Feed vrei să apeși pe un card și să intri într-un ecran de Detail fără să pierzi Bottom Bar-ul sau, din contră, să îl acoperi curat.
În Expo Router, totul ține de foldere și fișiere speciale _layout.tsx. Nu mai declari navigatori peste navigatori în JS, ci le oglindești în sistemul de fișiere.
Structura pe care o folosesc eu în producție arată așa:
app/(tabs)/_layout.tsx-> definește navigatorul principal de tip Tabsapp/(tabs)/feed/_layout.tsx-> un Stack separat inclus în primul Tabapp/(tabs)/feed/index.tsx-> lista de feedapp/(tabs)/feed/[id].tsx-> detaliul postării
Notația cu paranteze (tabs) e un Group Route. Nu apare în URL-ul de deep link și nu afectează calea ecranelor, ci servește strict pentru aplicarea layout-ului de tab-uri peste rutele din interior.
Trade-off-uri sincere
Să fim clari: Expo Router folosește tot React Navigation sub capotă. Nu e o re-inventare a roții, ci un wrapper foarte deștept deasupra lui.
Merge excepțional pentru URL-uri, deep links și type-safety generat automat. Totuși, e ceva mai puțin flexibil când ai cazuri dubioase de navigație condiționată dinamic la runtime. De exemplu, dacă ai un flow bizart de onboarding care depinde de 4 flag-uri din backend înainte să știi ce ecran renderezi primul, imperative routing-ul clasic din React Navigation încă îți oferă un control mai granular fără hack-uri de redirect în useEffect.
Voi ce folosiți pe proiectele curente? Ați făcut pasul spre Expo Router sau ați rămas pe React Navigation pur?