Teraz, kiedy dowiedzieliśmy się o
wszystkich tych alternatywach, oczywistym pytaniem jest, które podejście należy zastosować w swojej aplikacji?
Teraz myślę, że przez cały kurs widziałeś, że korzystanie z expo jest niesamowitym doświadczeniem programistycznym,
wszystko jest super szybkie, łatwo jest testować zmiany zarówno na symulatorach, jak i na rzeczywistych urządzeniach.
Nie trzeba budować lokalnie, dlatego
można również budować i testować dla systemu iOS, w systemach Windows i Linux, co nie jest możliwe bez
zarządzanego przepływu pracy i to
wszystko jest całkiem fajne.
Ale gdy porównamy expo do ustawień innych niż expo i non-expo, mam na myśli zarówno utworzenie go za
pomocą React Native CLI, jak i użycie samego przepływu pracy expo,
wtedy oczywiście musimy porównać wszystkie rzeczy.
Tak jak wspomniano w expo, z zarządzanym przepływem pracy, jest łatwy w użyciu, łatwy w rozwoju, non-expo
oznacza więcej ręcznej konfiguracji i tak dalej.
Teraz będziesz mieć łatwy czas na wdrożenie aplikacji, co zobaczysz również w sekcji poświęconej wdrażaniu, a
nawet możesz zbudować i wdrożyć na iOS, jeśli jesteś na komputerze z systemem Windows
lub Linux, co jest niemożliwe bez zarządzanego przepływu pracy.
Więc masz tam pewne ograniczenia i wdrożenie, jak zobaczysz, zajmuje również więcej pracy ręcznej,
tak jak ogólnie działa przepływ pracy niezwiązany z expo. W świecie przepływu pracy zarządzanym przez expo mamy również bogaty
zestaw rodzimych modułów, więc
wszystkie te interfejsy API expo, które są zawsze łatwe w użyciu, tylko zainstalowane expo, nie wymagają żadnej konfiguracji, więc
to
naprawdę niesamowite i masz ładny prawie wszystko, czego można chcieć w natywnej aplikacji
- kamera, lokalizacja, system plików - to wszystko.
Jeśli czasem potrzebujesz czegoś, co nie jest obsługiwane, lub musisz napisać własny
kod macierzysty, który chcesz połączyć z React Native, własny pakiet lub cokolwiek to jest, rozwiązaniem non-expo jest rozwiązanie.
Możesz więc użyć dowolnego kodu natywnego, ale oczywiście musisz go skonfigurować ręcznie, co może być łatwe
dzięki linkowi React Native, jak widziałeś, a nawet niektórym bibliotekom z automatycznym łączeniem, ale możesz także mieć biblioteki,
które wymagają większego wysiłku.
Ponadto warto zauważyć, że biblioteki innych firm muszą być utrzymywane, aby być na bieżąco
z React Native i nowszymi wersjami React Native, ale także muszą być na bieżąco z
Androidem i iOS,
prawda, ponieważ te platformy ewoluuj i wprowadzaj nowe funkcje lub przestarzałe stare funkcje.
Interfejsy API expo są gwarantowane, ponieważ są utrzymywane, ponieważ zespół expo jest aktywny, pracuje nad tym
i jest to cały ekosystem, który działa razem.
Może to nie być prawdą w przypadku wszystkich
pakietów innych firm, więc to dodatkowe bezpieczeństwo, które otrzymujesz dzięki pakietom expo, jest zdecydowanie całkiem miłe.
To powiedziawszy, jak zobaczyłeś w czystym przepływie pracy, możesz oczywiście dodać pewne, ale nie wszystkie interfejsy
API expo do niezarządzanych
aplikacji, jest to możliwe, ale zajmuje trochę więcej pracy. Teraz oczywiście zarządzany przepływ pracy ma swoje wady, jest to otoczka
wokół Twojej aplikacji, która oczywiście wpływa zarówno na rozmiar, jak i wydajność, najprawdopodobniej
nie w sposób, który poczujesz lub zobaczysz, ale warto zauważyć, że istnieje dodatkowe cienkie opakowanie i nie masz tego
w zwykłym przepływie pracy lub po prostu pracując z React Native CLI i oczywiście,
jak wspomniano, jesteś ograniczony do wbudowanych modułów natywnych.
Jest ich sporo i prawdopodobnie wszystko, czego możesz potrzebować, ale jeśli
potrzebujesz czegoś innego, co nie jest wbudowane w expo,
więc API, który nie jest obsługiwany przez expo, to nie ma sposobu, aby
uruchomić go, to potrzebujesz do wysuwania, ponieważ tylko non-expo,
a przez to mam na myśli, że niezarządzane aplikacje przepływu pracy obsługują wszystkie pakiety innych firm i wszystkie rodzime moduły,
których możesz chcieć użyć.
Dlatego proponuję, aby w przypadku większości aplikacji, prawie wszystkich aplikacji,
pracujesz z programem expo ze względu na wspaniałe wrażenia programistyczne i dużą elastyczność.
Ponieważ zawsze możesz się wysunąć, nie ma wiele do stracenia, możesz zawsze wrócić do aplikacji zarządzanej bez expo,
jeśli chcesz,
tak jak widziałeś, zaczynając od takiej aplikacji non-expo, więc z
samą aplikacją lub nawet z tylko aplikacja React Native CLI to dobry pomysł,
jeśli wiesz, że będziesz potrzebować wielu natywnych funkcjonalności, które nie są obsługiwane przez expo lub jeśli budujesz
aplikację o wysokiej wydajności, w której każdy kilobajt dodatkowego opakowania jest ważny, to oczywiście może zaczynać
się od takiej aplikacji, ale poza tym naprawdę nie widzę żadnego silnego powodu, aby nie korzystać z
expo, a zwłaszcza,
jeśli nie pracujesz w dużym zespole, w korporacji itp., ponieważ mogę również tworzyć
aplikacje na iOS w systemie Windows jest naprawdę miłą rzeczą, więc sam
jest także dobrym powodem do pozostania w zarządzanym świecie. To są moje dwa centy na tym, ponieważ możesz wysunąć,
to nie jest tak,
że musisz trzymać się jednego rozwiązania,
jeśli zaczniesz z nim, po prostu wracając od samego początku lub konfiguracja React Native CLI tylko do zarządzanego przepływu
pracy jest trochę trudniejsze, ponieważ tam musisz utworzyć nowy projekt zarządzany przez expo, skopiować
kod i jeśli używałeś bibliotek stron trzecich, które nie są z expo, nie będziesz już mógł z nich
korzystać.
Tak więc przejście z powrotem może
być trudne, przejście z expo zarządzanego na expo niezarządzany, co jest dość łatwe z wysuwaniem.