Nachdem wir nun alle diese Alternativen
kennengelernt haben, ist die offensichtliche Frage, welchen Ansatz Sie für Ihre Anwendung verwenden sollten.
Während des gesamten Kurses haben Sie gesehen, dass die Verwendung von expo im Allgemeinen eine großartige Entwicklungserfahrung
ist. Alles ist superschnell und es ist einfach, Änderungen sowohl auf Simulatoren als auch auf realen Geräten zu testen.
Sie müssen nicht lokal erstellen,
daher können Sie auch für und unter iOS, auf Windows-Systemen und Linux erstellen und testen, was ohne den verwalteten Workflow
nicht möglich ist, und das
ist alles ziemlich cool.
Aber wenn wir Expo mit Nicht-Expo-Setups und mit Nicht-Expo vergleichen, meine ich sowohl das Erstellen mit React
Native CLI als auch die Verwendung eines nackten Expo-Workflows, dann müssen
wir natürlich alle Dinge vergleichen.
Wie bei expo erwähnt, ist es mit dem verwalteten Workflow einfach zu verwenden, einfach zu entwickeln, Nicht-Expo
bedeutet mehr manuelle Einrichtung und so weiter.
Jetzt können Sie Ihre App auch problemlos bereitstellen, wie Sie auch im Abschnitt zur Bereitstellung sehen, und Sie
können sogar für iOS erstellen und bereitstellen, wenn Sie sich auf einem Windows- oder Linux-Computer
befinden. Dies ist ohne den verwalteten Workflow nicht möglich.
Dort gibt es einige Einschränkungen, und die Bereitstellung erfordert, wie Sie sehen werden, auch mehr
manuelle Arbeit, wie dies der Nicht-Expo-Workflow im Allgemeinen tut. In der Welt der von der Messe verwalteten Workflows haben wir
auch eine große Auswahl
an nativen Modulen, sodass all diese Expo-APIs, die immer einfach zu verwenden sind, nur eine installierte Messe, kein Setup benötigen. Das ist
wirklich
erstaunlich und Sie sind hübsch geworden Vieles, was Sie sich von einer nativen App
wünschen können - Kamera, Speicherort, Dateisystem - alles ist vorhanden.
Wenn Sie manchmal etwas benötigen, das jedoch nicht unterstützt wird, oder Ihren eigenen nativen Code
schreiben müssen, den Sie mit React Native, Ihrem eigenen Paket oder was auch immer verbinden möchten, dann ist non-expo die Lösung.
Dort können Sie also jeden nativen Code verwenden, aber natürlich müssen Sie ihn manuell einrichten. Dies ist möglicherweise einfach
mit dem React Native-Link, wie Sie gesehen haben, oder sogar mit einigen automatisch verknüpften Bibliotheken, aber Sie haben möglicherweise auch
Bibliotheken, die mehr Aufwand erfordern.
Darüber hinaus ist zu beachten, dass natürlich Bibliotheken von Drittanbietern gepflegt werden müssen, um mit React Native und neueren
Versionen von React Native auf dem neuesten Stand zu bleiben, aber auch mit Android und iOS, um auf dem neuesten
Stand zu bleiben, da
diese Plattformen Entwickeln Sie auch neue Funktionen und führen Sie sie ein oder lehnen Sie alte Funktionen ab.
Die Expo-APIs werden garantiert beibehalten, da das Expo-Team aktiv ist, daran arbeitet
und ein ganzes Ökosystem zusammenarbeitet.
Dies gilt möglicherweise nicht für alle Pakete von
Drittanbietern. Diese zusätzliche Sicherheit, die Sie mit den Expo-Paketen erhalten, ist auf jeden Fall sehr gut.
Wie Sie beim nackten Workflow gesehen haben, können Sie natürlich auch bestimmte, aber nicht alle Expo-APIs
zu nicht verwalteten Apps
hinzufügen. Dies ist möglich, erfordert jedoch etwas mehr Arbeit. Jetzt hat der verwaltete Workflow natürlich Nachteile, es ist ein Wrapper um Ihre App
und das wirkt sich natürlich sowohl auf die Größe als auch auf die Leistung aus, höchstwahrscheinlich
nicht auf eine Weise, die Sie fühlen oder sehen werden, aber es ist erwähnenswert, dass es einen dünnen zusätzlichen Wrapper gibt und Sie haben
das nicht im nackten Workflow oder wenn Sie nur mit der React Native CLI arbeiten, und natürlich
sind Sie, wie bereits erwähnt, auf die integrierten nativen Module beschränkt.
Es gibt eine Reihe von diesen und wahrscheinlich alles, was Sie
jemals brauchen könnten, aber wenn Sie etwas anderes benötigen, das
nicht in expo integriert ist, also eine API, die von expo nicht unterstützt wird, dann
gibt es keine Möglichkeit, es zum Laufen zu bringen, dann
brauchen Sie Auswerfen, weil nur Nicht-Expo und damit nicht verwaltete Workflow-Apps alle Pakete von Drittanbietern und alle nativen Module unterstützen, die
Sie möglicherweise verwenden möchten.
Daher würde ich vorschlagen, dass Sie für die meisten Apps, wahrscheinlich für fast
alle Apps, aufgrund der großartigen Entwicklungserfahrung und der großen Flexibilität, die Sie dort haben, mit expo arbeiten.
Da Sie immer auswerfen können, gibt es nicht viel zu verlieren. Sie können jederzeit zu einer nicht von der Messe
verwalteten App
zurückkehren, wenn Sie möchten, wie Sie gesehen haben, beginnend mit einer solchen
Nicht-Expo-App, also mit einer nackten App oder sogar mit Nur eine React Native CLI-App ist
eine gute Idee, wenn Sie wissen, dass Sie viele native Funktionen benötigen, die von der Messe nicht unterstützt werden,
oder wenn Sie eine Hochleistungsanwendung erstellen, bei der jedes Kilobyte zusätzliche Verpackung wichtig ist, dann sind Sie es
natürlich Vielleicht fangen wir mit einer solchen App an, aber ansonsten sehe ich keinen starken Grund, warum ich nicht expo
verwenden sollte, und insbesondere,
wenn Sie nicht in einem großen Team, in einem Unternehmen oder ähnlichem arbeiten und iOS-Apps
auch unter Windows erstellen können ist wirklich eine schöne Sache, so dass allein auch
ein guter Grund ist, in der verwalteten Welt zu bleiben. Das sind also meine zwei Cent dafür, da Sie auswerfen
können, ist es nicht
so, dass Sie sich an eine Lösung
halten müssen, wenn Sie damit beginnen. Es ist ein bisschen, nur vom nackten oder dem React Native CLI-Setup zum verwalteten
Workflow zurückzukehren Dies ist schwieriger, da Sie dort ein neues von der Expo verwaltetes Projekt erstellen,
Ihren Code kopieren und Bibliotheken von Drittanbietern verwenden müssen, die nicht von der Expo stammen. Sie können sie dann nicht
mehr verwenden.
Das Zurückschalten kann also schwierig
sein. Das Wechseln von expo-verwaltet zu expo-nicht verwaltet ist beim Auswerfen ziemlich einfach.