// app/(tabs)/_layout.tsx
import { Tabs } from 'expo-router';
import { Ionicons } from '@expo/vector-icons';
export default function TabsLayout() {
return (
<Tabs screenOptions={{ tabBarActiveTintColor: '#007AFF' }}>
<Tabs.Screen
name="index"
options={{
title: 'Home',
tabBarIcon: ({ color }) => <Ionicons name="home" size={24} color={color} />,
}}
/>
<Tabs.Screen
name="profile"
options={{
title: 'Profil',
tabBarIcon: ({ color }) => <Ionicons name="person" size={24} color={color} />,
}}
/>
</Tabs>
);
}Am tot văzut discuții pe forum despre Expo Router și dacă merită migrat de la clasicul React Navigation. Am făcut tranziția asta acum vreo 6 luni pe o aplicație cu 18k useri activi și am învățat câteva lecții pe pielea mea. Vă zic direct ce merită și cum configurezi structura de tab + stack nested fără să-ți prinzi urechile în foldere.
De ce am făcut pasul și care-i miza
React Navigation e standardul de aur de ani de zile. E solid, dar are o mare problemă: boilerplate-ul. Când ai zeci de ecrane, fișierul de configurare a rutei devine un monstru de mii de linii. Deep linking-ul era și el o întreagă aventură de configurat manual, plină de regex-uri și erori greu de debugat.
Expo Router rezolvă asta prin file-based routing, exact ca în Next.js. Faci un folder, trântești un fișier și ai ruta gata. Ba mai mult, deep linking-ul funcționează direct, fără să configurezi nimic în plus. La ultimul proiect, am economisit cam 30% din timpul de development pe partea de navigare pură.
Trade-off-ul sincer: Unde dă rateuri
Dar hai să fim realiști, nu e totul perfect. Cel mai mare minus apare la gestionarea stării globale. Dacă ai ecrane care trebuie blocate condiționat (de exemplu, un ecran de checkout accesibil doar dacă userul are un anumit status în Redux sau Zustand), cu Expo Router e ceva mai greu.
În React Navigation clasic, puneai un simplu conditonal rendering în navigator. În Expo Router, trebuie să folosești un root layout care ascultă de starea globală și face redirect-uri imperatice cu router.replace. Nu e imposibil, dar codul devine mai fragmentat și uneori te lovești de bug-uri ciudate de render timing la pornirea aplicației.
Cum configurezi Tab + Stack nested
Cea mai frecventă problemă de care m-am lovit la migrare a fost imbricarea ecranelor. Vrei un ecran de tip Tabs (Home, Setări) și vrei ca din Home, când dai click pe un produs, să se deschidă un ecran de detalii. Întrebarea e: vrei ca ecranul de detalii să aibă tab bar-ul jos, sau să se deschidă peste el (fullscreen)?
Secretul stă în parantezele rotunde din denumirea folderelor. Folderele cu paranteze, gen (tabs), sunt grupuri logice care nu apar în URL-ul rutei.
Dacă vrei ca ecranul de detalii să acopere tab bar-ul (fullscreen stack), structura trebuie să arate așa:
app/_layout.tsx(Root Stack)app/(tabs)/_layout.tsx(Tabs Navigator)app/(tabs)/index.tsx(Ecranul Home)app/details/[id].tsx(Ecranul de detalii, în afara grupului de taburi)
Dacă vrei ca ecranul să rămână în interiorul tab-ului de Home (cu tab bar-ul vizibil jos), pui folderul de detalii direct în grupul de tab-uri. Pe scurt, organizezi folderele exact așa cum vrei să se comporte navigarea vizuală.
Cum arată layout-ul de tab-uri
Iată cum configurezi rapid fișierul de layout pentru tab-uri. E simplu, curat și folosește noul API din SDK 50/51. Codul de mai jos se ocupă de definirea tab-urilor de bază în interiorul grupului (tabs).