Expo Router ha cambiato come penso alla navigazione

Per anni ho gestito la navigazione in React Native come si faceva: stack navigator, tab navigator, configurazione a runtime in un file dedicato. React Navigation è uno strumento maturo, ben documentato, e lo usavo senza problemi particolari.

Poi ho adottato Expo Router per ReD Sposi, e mi sono reso conto che il problema non era la libreria. Era il modello mentale.

Come funzionava prima

Con React Navigation, la struttura delle schermate è dichiarata nel codice. Hai un NavigationContainer, dentro ci metti uno Stack.Navigator, dentro ci metti gli Stack.Screen, ognuno con un componente associato. Se vuoi tab, annidi un Tab.Navigator. Se vuoi modal, li aggiungi come schermate con presentazione diversa.

Il risultato è un albero dichiarato esplicitamente, spesso in un file unico che cresce con l'app. Non è brutto — è solo che la struttura della navigazione vive separata dalla struttura dei file.

// navigazione dichiarata nel codice
<Stack.Navigator>
  <Stack.Screen name="Home" component={HomeScreen} />
  <Stack.Screen name="Profile" component={ProfileScreen} />
  <Stack.Screen name="Settings" component={SettingsScreen} />
</Stack.Navigator>

Come funziona adesso

Con Expo Router, la navigazione è il filesystem. Crei un file, esiste una schermata. La struttura delle cartelle è la struttura dell'app.

app/
  (tabs)/
    index.tsx       → tab principale
    gallery.tsx     → tab galleria
    chat.tsx        → tab chat
  invite.tsx        → schermata fuori dai tab
  _layout.tsx       → layout radice

Non c'è nessun file di configurazione della navigazione. Non c'è nessun array di schermate da mantenere sincronizzato con i componenti reali. La struttura è la documentazione.

Il cambio che non mi aspettavo

La differenza superficiale è che scrivi meno codice di configurazione. Ma il cambio reale è dove vive la mappa dell'app nella tua testa.

Con React Navigation, devo tenere a mente due strutture parallele: la struttura dei file dei componenti e la struttura della navigazione configurata altrove. Se aggiungo una schermata, devo aggiornarla in entrambi i posti. Se rimuovo una schermata, devo ricordarmi di rimuoverla anche dal navigator. Sono strutture che tendono a divergere.

Con Expo Router, esiste una sola struttura. Il file è la schermata, la cartella è il gruppo, il _layout.tsx è il container. Quando cerco dove vive una schermata, cerco nel filesystem — non in un file di configurazione che potrebbe essere diventato arbitrariamente complesso.

Questo non è un vantaggio di ergonomia. È un vantaggio cognitivo: c'è una cosa in meno da tenere in testa mentre lavoro.

Il parallelo con Next.js

Expo Router è costruito sulle stesse idee dell'App Router di Next.js — non è una coincidenza, è lo stesso team. E il parallelo regge abbastanza bene.

Come in Next.js, hai _layout.tsx al posto di layout.tsx, index.tsx per la root di una cartella, gruppi tra parentesi (group) per organizzare schermate senza aggiungere segmenti all'URL (o in questo caso, alla navigazione). Se hai esperienza con il App Router di Next.js, gran parte del modello mentale è già tuo.

Per me, che lavoro in entrambi gli ambienti, questo ha azzerato quasi completamente il costo di contesto switching tra web e mobile dal punto di vista della navigazione.

Dove si sente ancora il peso

Expo Router non è senza rughe.

Il deep linking e la gestione dei parametri di navigazione sono più verbosi di quanto dovrebbero — useLocalSearchParams() funziona, ma la tipizzazione è debole di default e richiede un po' di lavoro manuale per essere sicura.

I modal e le presentazioni native (bottom sheet, full-screen modal) si configurano nel _layout.tsx e il meccanismo è meno intuitivo rispetto alla libertà di React Navigation.

E Expo Router ha senso solo dentro l'ecosistema Expo. Se stai costruendo con bare React Native senza Expo, non è un'opzione.

Vale la pena?

Per la maggior parte dei progetti nuovi in Expo: sì. Il modello file-based riduce la complessità strutturale in modo reale, e l'allineamento con Next.js App Router abbassa il costo cognitivo se lavori in entrambi gli ambienti.

Ma la ragione più solida non è tecnica — è che un'app la cui struttura puoi capire aprendo l'esplora file è un'app più facile da mantenere, spiegare, e fare crescere. E questo vale sempre.