Przejdź do treści głównej

jeden post z tagiem "events"

Zobacz wszystkie tagi

Podsumowanie spotkania w San Francisco

· 8 minut czytania
Héctor Ramos
Héctor Ramos
Former Developer Advocate @ Facebook
Nieoficjalne Tłumaczenie Beta

Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt. Znalazłeś błąd? Zgłoś problem →

W zeszłym tygodniu miałem okazję uczestniczyć w spotkaniu React Native w siedzibie Zyngi w San Francisco. Z około 200 uczestnikami było to świetne miejsce, by poznać innych programistów z mojej okolicy, którzy również interesują się React Native.

Szczególnie interesowało mnie, jak React i React Native są wykorzystywane w firmach takich jak Zynga, Netflix i Airbnb. Program wieczoru przedstawiał się następująco:

  • Szybkie prototypowanie w React

  • Projektowanie API dla React Native

  • Łączenie światów: Wykorzystanie React Native w istniejących bazach kodu

Ale najpierw wydarzenie rozpoczęło się od krótkiego wprowadzenia i podsumowania najnowszych wiadomości:

Jeśli jedno z tych spotkań odbywa się w Waszej okolicy, bardzo polecam wziąć udział!

Szybkie prototypowanie w React w Zynga​

Po serii wiadomości nastąpiło krótkie wprowadzenie od Zyngi, naszego gospodarza wieczoru. Abhishek Chadha opowiedział, jak wykorzystują React do szybkiego prototypowania nowych doświadczeń mobilnych, demonstrując prototyp aplikacji podobnej do Draw Something. Stosują podejście podobne do React Native, zapewniając dostęp do natywnych API poprzez mostek. Zademonstrował to, robiąc zdjęcie publiczności aparatem urządzenia, a następnie rysując komuś kapelusz na głowie.

Projektowanie API dla React Native w Netflix​

Następnie pierwszy główny wykład wieczoru. Clarence Leung, starszy inżynier oprogramowania w Netflix, przedstawił prelekcję o projektowaniu API dla React Native. Najpierw wskazał dwa główne typy bibliotek: komponenty jak paski zakładek czy selektory dat oraz biblioteki zapewniające dostęp do natywnych usług jak galeria zdjęć czy płatności w aplikacji. Przy tworzeniu biblioteki do React Native można podejść na dwa sposoby:

  • Dostarczać komponenty specyficzne dla platformy

  • Tworzyć bibliotekę wieloplatformową z podobnym API dla Androida i iOS

Każde podejście ma swoje własne uwarunkowania i to od Was zależy, co najlepiej odpowiada Waszym potrzebom.

Podejście #1

Jako przykład komponentów specyficznych dla platformy Clarence omówił DatePickerIOS i DatePickerAndroid z rdzenia React Native. W iOS selektory dat są renderowane jako część UI i łatwo je osadzić w istniejącym widoku, podczas gdy na Androidzie są prezentowane modalnie. W tym przypadku sensowne jest dostarczanie oddzielnych komponentów.

Podejście #2

Selektor zdjęć działa natomiast w podobny sposób zarówno na Androida, jak i iOS. Występują niewielkie różnice — Android na przykład nie grupuje zdjęć w foldery tak jak iOS (np. Selfie) — ale można je łatwo obsłużyć za pomocą instrukcji if i komponentu Platform.

Niezależnie od wybranego podejścia, warto minimalizować powierzchnię API i budować biblioteki dedykowane pod konkretną aplikację. Przykładowo, framework zakupów w aplikacji na iOS obsługuje jednorazowe zakupy konsumpcyjne oraz odnawialne subskrypcje. Jeśli twoja aplikacja będzie obsługiwać tylko zakupy konsumpcyjne, możesz pominąć obsługę subskrypcji w swojej bibliotece cross-platformowej.

Po prezentacji Clarence'a odbyła się krótka sesja Q&A. Jedną z ciekawostek, które się podczas niej pojawiły, była informacja, że około 80% kodu React Native napisanego dla tych bibliotek w Netflixie jest współdzielone między Androida i iOS.

Łączenie światów: React Native w istniejących bazach kodu​

Ostatnią prezentację wieczoru wygłosił Leland Richardson z Airbnb. Skupiała się ona na wykorzystaniu React Native w istniejących bazach kodu. Wiedziałem już, jak łatwo napisać nową aplikację od zera w React Native, dlatego szczególnie interesowały mnie doświadczenia Airbnb z wdrażaniem React Native w ich istniejących natywnych aplikacjach.

Leland rozpoczął od rozróżnienia aplikacji greenfield i brownfield. Greenfield oznacza rozpoczęcie projektu bez konieczności uwzględniania wcześniejszej pracy. Przeciwieństwem są projekty brownfield, gdzie trzeba brać pod uwagę istniejące wymagania projektu, procesy deweloperskie i różnorodne potrzeby zespołów.

Podczas pracy nad aplikacją greenfield, CLI React Native konfiguruje jedno repozytorium dla Androida i iOS, gdzie wszystko po prostu działa. Pierwszym wyzwaniem dla wdrożenia React Native w Airbnb był fakt, że aplikacje na Androida i iOS miały osobne repozytoria. Firmy z wieloma repozytoriami muszą pokonać pewne przeszkody, zanim będą mogły zastosować React Native.

Aby rozwiązać ten problem, Airbnb najpierw utworzyło nowe repozytorium na kod React Native. Użyli serwerów CI do zlustrowania repozytoriów Androida i iOS do tego nowego repozytorium. Po uruchomieniu testów i zbudowaniu bundla, artefakty buildowe są synchronizowane z powrotem do repozytoriów Androida i iOS. To pozwala inżynierom mobilnym pracować nad natywnym kodem bez zmiany środowiska deweloperskiego. Nie muszą instalować npm, uruchamiać packagera ani pamiętać o budowaniu bundla JavaScript. Inżynierowie piszący kod React Native nie muszą martwić się synchronizacją kodu między Androidem i iOS, ponieważ pracują bezpośrednio w repozytorium React Native.

Rozwiązanie to ma jednak wady — głównie niemożność wysyłania aktualizacji atomowych. Zmiany wymagające kombinacji kodu natywnego i JavaScript wymagały trzech osobnych pull requestów, które wszystkie musiały być ostrożnie wdrażane. Aby uniknąć konfliktów, CI nie pozwalał na synchronizację zmian do repozytoriów Androida/iOS, jeśli master zmienił się podczas budowania. To powodowało długie opóźnienia w dni o wysokiej częstotliwości commitów (np. przy wydawaniu nowych wersji).

Airbnb przeszło następnie na podejście mono-repo. Na szczęście było to już rozważane, a gdy zespoły Androida i iOS oswoiły się z React Native, chętnie przyspieszyły przejście na mono-repo.

Rozwiązało to większość problemów związanych z podejściem rozdzielonych repozytoriów. Leland zauważył jednak, że powoduje to większe obciążenie serwerów kontroli wersji, co może być problemem dla mniejszych firm.

Problem nawigacji​

Druga część prezentacji Lelanda skupiła się na temacie bliskim memu sercu: problemie nawigacji w React Native. Mówił o mnogości bibliotek nawigacyjnych w React Native — zarówno oficjalnych, jak i społecznościowych. Wspomniał NavigationExperimental jako rozwiązanie obiecujące, które ostatecznie nie spełniło ich oczekiwań.

W rzeczywistości żadna z istniejących bibliotek nawigacyjnych nie sprawdza się dobrze w przypadku aplikacji typu brownfield. Taka aplikacja wymaga, aby stan nawigacji był w pełni kontrolowany przez natywną aplikację. Na przykład, jeśli sesja użytkownika wygaśnie podczas prezentowania widoku React Native, natywna aplikacja powinna móc przejąć kontrolę i wyświetlić ekran logowania w razie potrzeby.

Airbnb chciało również uniknąć zastępowania natywnych pasków nawigacyjnych ich wersjami w JavaScripcie podczas przejścia, ponieważ efekt mógłby być zbyt drastyczny. Początkowo ograniczali się do widoków prezentowanych modalnie, ale to oczywiście stanowiło problem przy szerszym wdrażaniu React Native w ich aplikacjach.

Zdecydowali, że potrzebują własnej biblioteki. Biblioteka nosi nazwę airbnb-navigation. Nie została jeszcze udostępniona jako open source, ponieważ jest silnie powiązana z kodem Airbnb, ale planują jej wydanie do końca roku.

Nie będę szczegółowo omawiał API tej biblioteki, ale oto kluczowe wnioski:

  • Sceny muszą być wcześniej zarejestrowane

  • Każda scena jest wyświetlana we własnym RCTRootView. Są prezentowane natywnie na każdej platformie (np. na iOS używane są UINavigationController).

  • Główny ScrollView w scenie powinien być opakowany w komponent ScrollScene. Dzięki temu można wykorzystać natywne zachowania, jak stuknięcie w pasek stanu, aby przewinąć do góry na iOS.

  • Przejścia między scenami są obsługiwane natywnie, bez obaw o wydajność.

  • Przycisk wstecz na Androidzie jest obsługiwany automatycznie.

  • Mogą wykorzystywać stylizację paska nawigacyjnego opartą na View Controllerach poprzez bezinterfejsowy komponent Navigator.Config.

Należy też pamiętać o pewnych ograniczeniach:

  • Pasek nawigacyjny nie jest łatwo dostosowywalny w JavaScripcie, ponieważ jest komponentem natywnym. To celowe założenie, gdyż używanie natywnych pasków nawigacyjnych jest kluczowym wymogiem dla tego typu bibliotek.

  • ScreenProps muszą być serializowane/deserializowane przy przesyłaniu przez bridge, więc należy uważać przy przesyłaniu zbyt dużych ilości danych.

  • Stan nawigacji jest kontrolowany przez natywną aplikację (również kluczowy wymóg), więc rozwiązania jak Redux nie mogą manipulować stanem nawigacji.

Prezentacja Lelanda zakończyła się sesją Q&A. Ogólnie Airbnb jest zadowolone z React Native. Rozważają użycie Code Push do naprawy problemów bez przechodzenia przez App Store, a ich inżynierowie uwielbiają Live Reload, ponieważ nie muszą czekać na przebudowanie natywnej aplikacji po każdej drobnej zmianie.

Podsumowanie​

Wydarzenie zakończyło się dodatkowymi informacjami o React Native:

Spotkania to świetna okazja, aby poznać innych developerów w społeczności i uczyć się od nich. Z niecierpliwością czekam na kolejne spotkania React Native. Jeśli na któreś z nich trafisz, poszukaj mnie i daj znać, jak możemy uczynić React Native jeszcze lepszym narzędziem dla Ciebie!