Quindi ora che abbiamo imparato tutte
queste alternative, la domanda ovvia è: quale approccio dovresti usare per la tua applicazione?
Ora penso che nel corso del corso, hai visto che usare expo in generale è un'esperienza
di sviluppo eccezionale, tutto è super veloce, è facile testare le modifiche sia su simulatori che su dispositivi reali.
Non è necessario creare localmente, quindi
è anche possibile creare e testare per e su iOS, su sistemi Windows e Linux che non è possibile senza il
flusso di lavoro gestito ed
è tutto abbastanza interessante.
Ma quando confrontiamo le configurazioni expo con quelle non expo e con non expo, intendo sia crearlo con la
CLI React Native sia usare un flusso di lavoro bare expo, quindi
ovviamente dobbiamo confrontare tutte le cose.
Quindi, come accennato con expo, con il flusso di lavoro gestito, è facile da usare, facile da sviluppare, non
expo significa più configurazione manuale e così via.
Ora ti divertirai anche a distribuire la tua app come vedrai anche nella sezione di distribuzione e puoi
persino creare e distribuire per iOS se sei sulla macchina Windows o Linux, cosa che
non è possibile senza il flusso di lavoro gestito.
Quindi, ci sono alcune restrizioni lì e la distribuzione, come vedrai, richiede anche più lavoro
manuale, come il flusso di lavoro non expo in generale. Quando siamo nel mondo del flusso di lavoro gestito dall'Expo, abbiamo anche
una ricca serie di
moduli nativi, quindi tutte queste API dell'Expo che sono sempre facili da usare, solo un'Expo installata via, non hanno bisogno di alcuna configurazione,
quindi
è davvero incredibile e sei diventato carino tutto ciò che potresti desiderare in un'app
nativa lì - fotocamera, posizione, file system, è tutto lì.
Se a volte hai bisogno di qualcosa che non è supportato o hai bisogno di scrivere
il tuo codice nativo che vuoi connettere a React Native, il tuo pacchetto o qualunque cosa sia, allora non-expo è la soluzione.
Quindi lì puoi usare qualsiasi codice nativo ma, ovviamente, devi impostarlo manualmente e questo potrebbe essere facile con
il link React Native come hai visto o anche con alcune librerie di autolinking ma potresti avere anche librerie
che richiedono più sforzo.
Inoltre, vale la pena notare che ovviamente le librerie di terze parti devono essere mantenute per rimanere
aggiornate con React Native e le versioni più recenti di React Native ma devono anche rimanere aggiornate con
Android e iOS,
giusto, perché queste piattaforme anche evolvere e introdurre nuove funzionalità o deprecare le vecchie funzionalità.
Le API di expo sono abbastanza garantite da mantenere perché il team di expo è attivo, ci sta
lavorando ed è un intero ecosistema che lavora insieme.
Questo potrebbe non essere vero per tutti i pacchetti
di terze parti, quindi questa sicurezza aggiuntiva che si ottiene con i pacchetti expo è decisamente carina.
Detto questo, come hai visto con il flusso di lavoro nudo, puoi ovviamente aggiungere anche alcune API expo
ad app non gestite, ciò
è possibile ma richiede un po 'più di lavoro. Ora, ovviamente, il flusso di lavoro gestito ha dei lati negativi, è
un wrapper per la tua app e questo ovviamente influisce sia sulle dimensioni che sulle
prestazioni, molto probabilmente non in un modo che sentirai o vedrai ma vale la pena notare, c'è un sottile wrapper extra e non
lo hai nel flusso di lavoro nudo o quando lavori solo con la CLI React Native
e ovviamente, come detto, sei limitato ai moduli nativi incorporati.
Ci sono un sacco di quelli e probabilmente tutto ciò di cui potresti
mai aver bisogno ma se hai bisogno di qualcos'altro che non
è incorporato in Expo, quindi un'API che non è supportata da Expo, quindi non c'è modo
di farlo funzionare, quindi è necessario da espellere perché solo le
non-expo e con ciò intendo le app di flusso di lavoro non gestite supportano tutti i pacchetti di terze parti e tutti i moduli
nativi che potresti voler utilizzare.
Quindi il mio suggerimento sarebbe che per la maggior parte delle app, praticamente tutte
le app, probabilmente lavori con expo a causa della grande esperienza di sviluppo e della grande flessibilità che hai lì.
Dal momento che puoi sempre espellere, non c'è molto da perdere, puoi sempre tornare a un'app gestita non expo se
vuoi come
hai visto, a partire da un'app così non expo, quindi con un'app
nuda o addirittura con solo un'app CLI nativa di React è una buona idea
se sai che avrai bisogno di molte funzionalità native che non sono supportate da expo o se stai costruendo
un'applicazione ad alte prestazioni in cui ogni kilobyte di involucro extra conta, quindi ovviamente tu potrebbe iniziare con
un'app del genere, ma per il resto non vedo davvero alcun motivo per cui non usare expo e soprattutto
se non stai lavorando
in una grande squadra, in una società o qualcosa del genere, essendo in grado
di costruire app iOS anche su Windows è davvero una bella cosa, quindi anche
questo è un buon motivo per rimanere nel mondo gestito. Quindi questi sono i miei due centesimi su questo, dal
momento che puoi espellere,
non è come se dovessi attenersi a
una soluzione se inizi con essa, solo tornare indietro dalla CLI nativa nuda o React, solo l'installazione sul flusso di lavoro
gestito è un po ' più complicato perché lì, è necessario creare un nuovo progetto gestito
expo, copiare il codice e se sono state utilizzate librerie di terze parti che non sono expo, non sarà più
possibile utilizzarle.
Quindi tornare indietro può essere
difficile, passare da expo gestito a expo non gestito, è abbastanza facile con l'espulsione.