Então, agora que aprendemos sobre todas
essas alternativas, a pergunta óbvia é: qual abordagem você deve usar para seu aplicativo?
Agora, acho que ao longo do curso, você viu que usar a expo em geral é uma
experiência incrível de desenvolvimento, tudo é super rápido, é fácil testar alterações tanto em simuladores quanto em dispositivos reais.
Você não precisa criar localmente;
portanto, também é possível criar e testar para iOS, sistemas Windows e Linux, o que não é possível sem o
fluxo de trabalho gerenciado e
isso é muito legal.
Mas quando comparamos as configurações expo a não expo e com não expo, quero dizer, criando-o com o React Native
CLI ou usando um fluxo de trabalho de expo, então é claro
que temos que comparar todas as coisas.
Portanto, como mencionado na expo, com o fluxo de trabalho gerenciado, é fácil usar que, fácil de desenvolver, não expo
significa mais configuração manual e assim por diante.
Agora, você também terá facilidade em implantar seu aplicativo, como também verá na seção de implantação, e
poderá criar e implantar para iOS se estiver na máquina Windows ou Linux, algo que
não é possível sem o fluxo de trabalho gerenciado.
Portanto, existem algumas restrições e implantação, como você verá, também exige mais trabalho manual, como o
fluxo de trabalho que não é de exposição, em geral. Quando no mundo do fluxo de trabalho gerenciado da expo, também temos
uma rica variedade de módulos
nativos; portanto, todas essas APIs de expo que são sempre fáceis de usar, apenas uma expo instalada, não precisam de nenhuma configuração, então isso
é
realmente incrível e você fica bonito tudo o que você poderia querer em um aplicativo nativo
lá - câmera, localização, sistema de arquivos, está tudo lá.
Se, às vezes, você precisar de algo que não é suportado ou precisar escrever seu próprio
código nativo ao qual deseja se conectar ao React Native, seu próprio pacote ou o que for, então a não-expo é a solução.
Portanto, é possível usar qualquer código nativo, mas é claro, é necessário configurá-lo manualmente e isso pode ser fácil
com o link React Native como você viu ou mesmo em algumas bibliotecas de vínculo automático, mas você também pode ter
bibliotecas que exigem mais esforço.
Além disso, é importante notar que é claro que as bibliotecas de terceiros precisam ser mantidas para
manter-se atualizado com o React Native e as versões mais recentes do React Native, mas também precisam se
manter atualizados com o
Android e iOS, pois essas plataformas também evoluir e introduzir novos recursos ou descontinuar recursos antigos.
É garantido que as APIs da expo são mantidas porque a equipe da expo está ativa, está trabalhando nisso
e é um ecossistema inteiro que trabalha em conjunto.
Isso pode não ser verdade para todos os
pacotes de terceiros, portanto, essa segurança extra obtida com os pacotes expo é definitivamente muito boa.
Dito isso, como você viu com o fluxo de trabalho simples, é claro que também é possível adicionar certas APIs de
expo a aplicativos não gerenciados, mas
nem todas, isso é possível, mas exige um pouco mais de trabalho. Agora é claro que o fluxo de trabalho gerenciado tem desvantagens, é
um invólucro em torno de seu aplicativo e, claro, afeta o tamanho e o desempenho,
provavelmente não da maneira que você sentirá ou verá, mas vale a pena notar, há um invólucro extra fino e você não tem
isso no fluxo de trabalho simples ou quando apenas trabalha com a React Native CLI e,
é claro, como mencionado, está restrito aos módulos nativos integrados.
Existem vários deles e provavelmente tudo o que você pode precisar, mas
se você precisar de algo que não esteja incorporado na
expo, portanto, uma API que não seja suportada pela expo, não haverá como fazê-la funcionar,
então você precisará para ejetar porque apenas não expo e
com isso quero dizer que aplicativos de fluxo de trabalho não gerenciado suportam todos os pacotes de terceiros e todos os módulos nativos
que você pode querer usar.
Portanto, minha sugestão seria que, para a maioria dos aplicativos, provavelmente todos os aplicativos,
você trabalha com expo por causa da grande experiência de desenvolvimento e da grande flexibilidade que você tem lá.
Como você sempre pode ejetar, não há muito a perder, você sempre pode voltar para um aplicativo gerenciado que não seja
da expo,
se quiser, como você viu, começando com um aplicativo que não seja
da expo, portanto, com um aplicativo simples ou mesmo com apenas um aplicativo React Native
CLI é uma boa idéia, se você souber que precisará de muitas funcionalidades nativas que não são suportadas pela expo
ou se estiver criando um aplicativo de alto desempenho em que todos os kilobytes de empacotamento extra importam, é
claro que você pode começar com esse aplicativo, mas, caso contrário, não vejo realmente nenhuma razão forte para não usar
a expo e, especialmente,
se você não estiver trabalhando em uma equipe enorme, em uma corporação ou algo assim,
conseguir criar aplicativos iOS no Windows também é realmente uma coisa boa, e só
isso também é uma boa razão para permanecer no mundo gerenciado. Portanto, esses são meus dois centavos sobre isso, já que
você pode ejetar, não
é necessário ter uma solução se você
começar com ela, basta voltar do zero ou da configuração somente da CLI do React Native para o fluxo
de trabalho gerenciado. mais complicado porque lá, você precisa criar um novo projeto gerenciado da
expo, copiar seu código e, se você usou bibliotecas de terceiros que não são da expo, não poderá mais
usá-las.
Portanto, mudar de volta pode ser
difícil, alternar de expo gerenciado para expo não gerenciado, isso é muito fácil com a ejeção.