Entonces, ahora que hemos aprendido sobre
todas estas alternativas, la pregunta obvia es, ¿qué enfoque debe usar para su aplicación?
Ahora creo que a lo largo del curso, viste que usar expo en general es una experiencia
de desarrollo increíble, todo es súper rápido, es fácil probar los cambios tanto en simuladores como en dispositivos reales.
No necesita compilar localmente, por lo
tanto, también puede compilar y probar para y en iOS, en sistemas Windows y Linux, lo que no es posible sin
el flujo de trabajo administrado y
eso es bastante bueno.
Pero cuando comparamos configuraciones expo con configuraciones no expo y con no expo, me refiero a crearlo con React Native
CLI o usar un flujo de trabajo de expo simple, entonces, por
supuesto, tenemos que comparar todas las cosas.
Entonces, como se mencionó con expo, con el flujo de trabajo administrado, es fácil de usar que, fácil de
desarrollar, no expo significa más configuración manual, etc.
Ahora también tendrá un tiempo fácil para implementar su aplicación, como también verá en la sección de implementación e
incluso puede construir e implementar para iOS si está en la máquina Windows o Linux, algo
que no es posible sin el flujo de trabajo administrado.
Entonces, allí tiene algunas restricciones y la implementación, como verá, también requiere más trabajo manual, como
lo hace el flujo de trabajo no expo en general. Cuando estamos en el mundo del flujo de trabajo administrado por la expo,
también tenemos una gran variedad
de módulos nativos, por lo que todas estas API de expo, que siempre son fáciles de usar, solo una expo instalada, no necesita ninguna configuración,
así
que eso es realmente increíble y tienes bastante todo lo que pueda desear en una aplicación
nativa allí: cámara, ubicación, sistema de archivos, todo está ahí.
Si a veces necesita algo que no es compatible o necesita escribir su propio
código nativo que desea conectar a React Native, su propio paquete o lo que sea, entonces no-expo es la solución.
Entonces, puede usar cualquier código nativo, pero, por supuesto, debe configurarlo manualmente y eso podría ser fácil
con el enlace React Native como vio o incluso algunas bibliotecas de enlace automático, pero también puede tener bibliotecas
que requieren más esfuerzo.
Además, vale la pena señalar que, por supuesto, las bibliotecas de terceros deben mantenerse para mantenerse
actualizadas con React Native y las versiones más recientes de React Native, pero también deben mantenerse actualizadas
con Android e
iOS, porque estas plataformas también evolucione e introduzca nuevas características o desactive las características antiguas.
Se garantiza que las API de la expo se mantendrán porque el equipo de la expo está activo, está trabajando en
eso y es un ecosistema completo que funciona en conjunto.
Es posible que eso no sea cierto para todos los
paquetes de terceros, por lo que esta seguridad adicional que obtienes con los paquetes de exposición es definitivamente bastante agradable.
Dicho esto, como viste con el flujo de trabajo simple, por supuesto, también puedes agregar ciertas API de exposición a
aplicaciones no administradas, pero no
todas, eso es posible pero requiere un poco más de trabajo. Ahora, por supuesto, el flujo de trabajo administrado tiene inconvenientes, es un envoltorio
alrededor de su aplicación y eso, por supuesto, afecta tanto el tamaño como el rendimiento, lo
más probable es que no lo sienta o vea, pero vale la pena señalar, hay un envoltorio extra delgado y no tiene eso en
el flujo de trabajo simple o cuando solo trabaja con React Native CLI y, por supuesto,
como se mencionó, está restringido a los módulos nativos incorporados.
Hay un montón de esos y probablemente todo lo que pueda necesitar,
pero si necesita algo más que no esté integrado en expo,
por lo que una API que no es compatible con expo, entonces no hay forma de
que funcione, entonces necesita expulsar porque solo las aplicaciones no expo
y con eso quiero decir que las aplicaciones de flujo de trabajo no administradas admiten todos los paquetes de terceros y todos los
módulos nativos que desee utilizar.
Por lo tanto, mi sugerencia sería que para la mayoría de las aplicaciones, prácticamente todas
las aplicaciones, probablemente trabaje con expo debido a la gran experiencia de desarrollo y la gran flexibilidad que tiene allí.
Como siempre puede expulsar, no hay mucho que perder, siempre puede volver a una aplicación administrada no expo si lo
desea, como
comenzó, con una aplicación no expo, así que con una aplicación simple
o incluso con solo una aplicación React Native CLI es una buena idea si
sabe que necesitará muchas funcionalidades nativas que no son compatibles con expo o si está creando una aplicación de
alto rendimiento donde cada kilobytes de envoltura adicional es importante, entonces, por supuesto, podría comenzar con una aplicación
de este tipo, pero de lo contrario, realmente no veo una razón sólida por la que no usar expo
y especialmente si no
está trabajando en un gran equipo, en una corporación o algo así, poder crear
aplicaciones de iOS en Windows también es realmente algo agradable, por lo que solo
es una buena razón para permanecer en el mundo administrado. Así que esos son mis dos centavos sobre eso, ya
que puedes expulsar, no
es como si tuvieras que seguir con
una solución si comienzas con ella, solo regresar de lo básico o la configuración React Native CLI solo para el
flujo de trabajo administrado es un poco más complicado porque allí, debe crear un nuevo
proyecto administrado por expo, copiar su código y si utilizó bibliotecas de terceros que no son de expo, ya no
podrá usarlas.
Entonces, volver a cambiar puede ser
difícil, cambiar de expo administrado a expo no administrado, eso es bastante fácil con la expulsión.