import { Stack } from 'expo-router';
export default function AppLayout() {
return (
<Stack screenOptions={{ headerShown: false }}>
{/* Tab-urile principale */}
<Stack.Screen name="(tabs)" />
{/* Ecranul care va acoperi tab-urile */}
<Stack.Screen
name="details"
options={{
headerShown: true,
title: 'Detalii Produs',
presentation: 'card', // sau 'modal' pentru iOS style
}}
/>
</Stack>
);
}Am trecut recent prin procesul ăsta la un proiect cu peste 14.000 de utilizatori activi. Aplicația era scrisă cu React Navigation clasic, dar clientul voia neapărat notificări push care să deschidă ecrane specifice din adâncul aplicației (deep linking). Cine a configurat manual deep linking în React Navigation știe că e o rețetă sigură pentru dureri de cap și fișiere de configurare gigantice.
Așa că am luat decizia să migrăm la Expo Router. Am economisit cam 35% din codul dedicat navigării, dar tranziția n-a fost lipsită de obstacole.
Când merită să faci pasul și care-i prețul
Expo Router aduce conceptul de file-system routing din web (stil Next.js) direct pe mobil. Sună genial: pui un fișier în folderul app și ai o rută nouă. Totuși, trade-off-ul e masiv când vine vorba de flexibilitate.
Dacă ai o aplicație cu fluxuri dinamice complexe — de exemplu, ecrane care apar doar dacă userul are un anumit rol, un istoric de navigare custom pe care vrei să-l manipulezi programatic sau modaluri suprapuse bizar — structura rigidă de directoare a Expo Router s-ar putea să te încurce mai mult decât să te ajute. În schimb, dacă ai nevoie de deep linking out-of-the-box, suport web bun și o structură curată, migrarea merită fiecare secundă.
Structura tab + stack nested (Cum o faci corect)
Cea mai comună problemă de care m-am lovit a fost organizarea ecranelor când ai un Tab Navigator la bază, dar vrei ca unele ecrane să se deschidă ca un Stack peste tot ecranul (ascunzând bara de tab-uri), în timp ce altele trebuie să se deschidă în interiorul unui tab specific.
Cheia stă în gruparea folderelor folosind paranteze rotunde (group). Aceste foldere sunt ignorate de URL/rută, dar servesc la gruparea layout-urilor.
Pentru a avea un Tab bar jos, iar din interiorul unui tab să deschizi un ecran detaliat care ascunde tab-urile, structura ta de fișiere trebuie să arate așa:
app/_layout.tsx(Root Stack - gestionează auth state și ecranele full-screen modale)app/(app)/_layout.tsx(Stack-ul principal pentru utilizatorii logați)app/(app)/(tabs)/_layout.tsx(Tab Navigator-ul: Home, Search, Profile)app/(app)/(tabs)/index.tsx(Ecranul de Home)app/(app)/details.tsx(Ecranul detaliat care acoperă tab-urile)
Dacă ecranul de detalii ar fi fost în interiorul folderului (tabs), bara de jos ar fi rămas vizibilă. Mutându-l în (app), dar în afara (tabs), obții acel comportament nativ în care detaliile vin de la dreapta la stânga și acoperă complet ecranul.
Un exemplu practic de configurare
Iată cum arată layout-ul principal din app/(app)/_layout.tsx care definește stack-ul părinte, permițând grupului de tab-uri să coexiste cu ecranele full-screen.
În interiorul folderului (tabs), vei avea un alt _layout.tsx care configurează efectiv tab-urile folosind componenta <Tabs> din expo-router.
Ce am observat la performanță? Pe Android, tranzițiile dintre ecranele din Stack-ul root și cele din interiorul tab-urilor pot avea uneori un mic flicker dacă ai imagini grele nerezolvate la render. Pe iOS în schimb, totul rulează la 120Hz fără nicio problemă.
Dacă pornești un proiect complet nou (greenfield), sfatul meu e să mergi direct pe Expo Router. Te forțează să ai o structură organizată de la început. Dacă ai o aplicație veche de câțiva ani cu sute de ecrane în React Navigation, costul refactorizării s-ar putea să nu se justifice doar pentru "hype-ul" de file-system routing.
Voi ce folosiți în producție în momentul de față? Vă sperie structura bazată pe fișiere sau ați făcut deja trecerea?