Kod i zdrowie społeczności​

W ciągu ostatnich sześciu miesięcy ponad 550 współtwórców wprowadziło łącznie 2800 commitów do React Native. 400 współtwórców ze społeczności utworzyło ponad 1150 Pull Requestów, z których 820 Pull Requestów zostało scalonych.

Średnia dzienna liczba Pull Requestów w ostatnim półroczu wzrosła z trzech do około sześciu, mimo wydzielenia strony, CLI i wielu modułów z React Native w ramach inicjatywy Lean Core. Średnia liczba otwartych pull requestów spadła poniżej 25, a zazwyczaj odpowiadamy z sugestiami i recenzjami w ciągu kilku godzin lub dni.

Znaczące wkłady społeczności​

Chcielibyśmy wyróżnić kilka niedawnych wkładów, które uważamy za wyjątkowe:

• Dostępność: React Native 0.60 zawiera wiele ulepszeń API dostępności na Androida i iOS. Wszystkie nowe funkcje bezpośrednio wykorzystują API platformy bazowej, dzięki czemu integrują się z natywnymi technologiami asystującymi. Dziękujemy Marcowi Mulcahy'emu, Alanowi Kenyonowi, Estevão Lucasowi, Samowi Mathiasowi Weggersenowi i Janicowi Duplessis za ich wkład:

  • Dodatkowe role i stany dostępności oraz nowe API stanów dostępności. Dodano brakujące role dostępności dla różnych komponentów i nowe API dla lepszego wsparcia webowego.
  • AccessibilityInfo.announceForAccessibility. Dodano wsparcie dla Androida (wcześniej tylko iOS).
  • Rozszerzone wsparcie akcji dostępności. Dodano callbacki do obsługi akcji zdefiniowanych przez użytkownika.
  • Wsparcie flag dostępności iOS i wsparcie „redukcji ruchu”.
  • Ulepszenia dostępności klawiatury na Androidzie. Dodano właściwość clickable i callback onClick do wywoływania akcji przez nawigację klawiszową (uwaga: wkrótce zmiana nazwy na focusable).
  • Rysowanie tekstu za pomocą CALayers. Naprawiono problem z zanikaniem przeskalowanego tekstu na iOS.

• Nowy ekran aplikacji: Społeczność opracowała projekt nowego ekranu aplikacji zaimplementowany w 0.60. To pierwszy ekran widziany przez nowych użytkowników React Native. Teraz kieruje on do dokumentacji, a jego styl pasuje do nadchodzącego redesignu strony 🌟. Ogromne podziękowania dla Orty, Adama Shursona, Glaubera Castro, Karana Singha, Eliego Perkinsa, Lucasa Bento i Erica Lewisa za pracę i współpracę!

  • Zobacz nowy ekran aplikacji w serii „React Native Show“.

• Typy dla TurboModule: Nowy system TurboModules wymaga typów dla wszystkich modułów natywnych aby zagwarantować bezpieczeństwo typów w kodzie natywnym. W niecałe dwa tygodnie społeczność wysłała około 40 Pull Requestów, aby ukończyć tę pracę dla modułów natywnych z typami Flow. Oprócz osób już wymienionych, dziękujemy Michałowi Chudziakowi, Michałowi Pierzchale, Wojtkowi Szafrańcowi, Jeanowi Regisserowi i wszystkim, którzy wysłali przynajmniej jeden Pull Request.

• Haste: Od 2015 roku React Native używał systemu modułów "haste", który pozwala importować moduły za pomocą globalnego identyfikatora zamiast ścieżki względnej. Jest to wygodne, ale słabo obsługiwane przez wiele narzędzi. James Ide zaproponował usunięcie haste, podobnie jak zrobił to React lata temu. Zaplanował całą pracę w ramach głównego zadania i wysłał 18 Pull Requestów, aby to zrealizować! Więcej szczegółów w jego wątku na Twitterze.

• Android Fragments: Propozycja Johna Shelleya umożliwiająca działanie React Native przez Android Fragments została scalona i będzie dostępna w wersji 0.61. Więcej o Android Fragments.

Lean Core​

Głównym celem Lean Core jest wydzielenie modułów z React Native do osobnych repozytoriów dla lepszej konserwacji. W ciągu pół roku repozytoria takie jak WebView, NetInfo, AsyncStorage, strona dokumentacji i CLI otrzymały łącznie ponad 800 Pull Requestów. Oprócz lepszej konserwacji, projekty te mogą być wydawane niezależnie częściej niż React Native.

Usunęliśmy również przestarzałe polyfille i legacy'owe komponenty. Polyfille były dawniej potrzebne do obsługi funkcji językowych jak Map i Set w starszych wersjach JavaScriptCore (JSC). Obecnie React Native dostarcza nowszą wersję JSC, więc polyfille zostały usunięte.

Prace nadal trwają, ale już widać pierwsze efekty odwrócenia trendu zwiększania rozmiaru aplikacji: rok temu w wersji 0.54 rozmiar pakietu JavaScript React Native wynosił 530kb, a w wersji 0.57 wzrósł do 607kb (+77kb). Obecnie na gałęzi master obserwujemy redukcję o 28kb do 579kb, co daje ponad 100kb różnicy!

Kończąc pierwszą fazę Lean Core, będziemy bardziej świadomie wprowadzać nowe API do React Native, stale optymalizować rozmiar i wydajność, oraz wspierać społeczność w przejmowaniu własności nad komponentami.

Opinie użytkowników​

Sześć miesięcy temu zapytaliśmy społeczność: „Co wam się nie podoba w React Native?”, co dało dobry przegląd problemów, z którymi się borykają. Odpowiedzieliśmy na ten post kilka miesięcy temu i teraz czas podsumować postępy w najważniejszych kwestiach:

• Aktualizacje: Społeczność React Native zjednoczyła siły, wprowadzając wiele usprawnień w procesie aktualizacji: autolinking, lepsze polecenie aktualizacji dzięki rn-diff-purge, strona pomocnicza do aktualizacji (wkrótce). Będziemy też informować o zmianach łamiących kompatybilność i nowych funkcjach poprzez posty na blogu przy każdym głównym wydaniu. Wiele z tych ulepszeń sprawi, że przyszłe aktualizacje poza wersją 0.60 będą znacznie prostsze.

• Wsparcie/niepewność: Wielu użytkowników było sfrustrowanych brakiem aktywności przy Pull Requestach i ogólną niepewnością co do zaangażowania Facebooka w React Native. Jak pokazaliśmy powyżej, możemy z całą pewnością stwierdzić, że jesteśmy gotowi na więcej Pull Requestów i z niecierpliwością czekamy na wasze propozycje i wkład!

• Wydajność: React Native 0.59 dostarczył nową, znacznie szybszą wersję JavaScriptCore (JSC). Dodatkowo pracujemy nad domyślnym włączaniem inline-requires i w ciągu najbliższych miesięcy przygotowaliśmy więcej ekscytujących aktualizacji.

• Dokumentacja: Niedawno rozpoczęliśmy gruntowną przebudowę i przepisanie całej dokumentacji React Native. Jeśli chcesz się przyłączyć, z radością przyjmiemy twoją pomoc!

• Ostrzeżenia w Xcode: Pozbyliśmy się wszystkich istniejących ostrzeżeń i dokładamy starań, by nie wprowadzać nowych.

• Hot Reloading: Zespół React pracuje nad nowym systemem hot reloadingu, który wkrótce zostanie zintegrowany z React Native.

Niestety, nie udało nam się jeszcze poprawić wszystkich obszarów:

• Debugowanie: Naprawiliśmy wiele uciążliwych błędów, z którymi ludzie spotykają się na co dzień, ale niestety nie osiągnęliśmy w tej kwestii tak dużego postępu, jak byśmy chcieli. Zdajemy sobie sprawę, że debugowanie w React Native nie jest idealne i w przyszłości nadamy temu priorytet.

• Symlinki w Metro: Niestety nie udało nam się jeszcze wdrożyć prostego rozwiązania tego problemu. Jednak użytkownicy React Native udostępnili różne obejścia, które mogą ci pomóc.

Biorąc pod uwagę liczne zmiany z ostatnich sześciu miesięcy, ponownie chcemy zadać wam to samo pytanie. Jeśli używasz najnowszej wersji React Native i masz uwagi, prosimy o komentarze w nowej edycji „Co wam się nie podoba w React Native?”

Ciągła integracja​

Facebook scala wszystkie Pull Requesty i wewnętrzne zmiany najpierw do swojego repozytorium, a dopiero potem synchronizuje commity z GitHubem. Infrastruktura Facebooka różni się od popularnych usług CI, więc nie wszystkie testy open source były uruchamiane wewnętrznie. Oznaczało to, że commity synchronizowane z GitHubem często łamały testy w projekcie open source, co zajmowało dużo czasu na naprawę.

Héctor Ramos z zespołu React Native spędził ostatnie dwa miesiące na ulepszaniu systemów ciągłej integracji zarówno w Facebooku, jak i na GitHubie. Większość testów open source jest teraz uruchamianych przed zatwierdzeniem zmian w React Native w Facebooku, co zapewni stabilność CI na GitHubie podczas synchronizacji commitów.

Co dalej​

Sprawdź koniecznie nasze prezentacje o przyszłości React Native! W ciągu najbliższych kilku miesięcy członkowie zespołu React Native z Facebooka wystąpią na konferencjach Chain React i React Native EU. Wypatrujcie też naszej kolejnej wersji - 0.60, która jest tuż za rogiem. To będzie ekscytujące ✨

W tym tygodniu Eli White wygłosił prezentację na F8 2019 o wykorzystaniu React Native w aplikacjach Facebooka na Androida i iOS. Z przyjemnością dzielimy się tym, nad czym pracowaliśmy przez ostatnie dwa lata i jakie mamy dalsze plany.

Zobacz nagranie na stronie developerów Facebooka:

Najważniejsze punkty prezentacji:​

• W latach 2017-2018 skupiliśmy się na największym produkcie React Native – Facebook Marketplace. Współpracowaliśmy z zespołem Marketplace, aby podnieść jakość i ulepszyć doświadczenia użytkowników. Obecnie Marketplace jest jednym z najwyższej jakości produktów w aplikacji Facebooka na Androida i iOS.

• Wydajność Marketplace stanowiła duże wyzwanie, szczególnie na średniej klasy urządzeniach z Androidem. W ciągu ostatniego roku skróciliśmy czas uruchamiania o ponad 50%, a kolejne ulepszenia są w drodze! Największe optymalizacje są wbudowywane w React Native i trafią do społeczności jeszcze w tym roku.

• Mamy pewność, że dzięki React Native możemy budować wysokiej jakości, wydajne aplikacje potrzebne Facebookowi. Ta pewność pozwoliła nam inwestować w większe projekty, takie jak przemyślenie fundamentów React Native.

• Microsoft wspiera i używa React Native for Windows, umożliwiając wykorzystanie istniejącej wiedzy i kodu do renderowania na platformie Universal Windows Platform. Śledźcie Microsoft Build w przyszłym tygodniu, aby usłyszeć więcej na ten temat.

Podcast React Radio o open source​

Prezentacja Eli'ego kończy się omówieniem naszych ostatnich działań w open source. W marcu podzieliliśmy się aktualizacją naszych postępów, a niedawno Nader Dabit i Gant Laborde zaprosili Christopha do rozmowy w swoim podcaście React Native Radio o React Native w open source.

Najważniejsze punkty podcastu:​

• Rozmawialiśmy o tym, jak zespół React Native w Facebooku podchodzi do open source i jak budujemy zrównoważoną społeczność dopasowaną do skali projektu.

• Realizujemy plan usuwania wielu modułów w ramach inicjatywy Lean Core. Moduły takie jak WebView czy React Native CLI otrzymały ponad 100 pull requestów od momentu ich wydzielenia.

• Następnie skupimy się na gruntownej przebudowie strony internetowej i dokumentacji React Native. Śledźcie nasze komunikaty!

Odcinek wkrótce pojawi się w Twojej ulubionej aplikacji podcastowej, a nagranie możesz odsłuchać już teraz:

Witamy w wydaniu React Native 0.59! To kolejna duża aktualizacja zawierająca 644 commity od 88 współtwórców. Wkład przyjmuje też inne formy, więc dziękujemy za zgłaszanie problemów, budowanie społeczności i edukowanie o React Native. Ten miesiąc przynosi długo wyczekiwane zmiany, mamy nadzieję że Wam się spodobają.

🎣 Hooks są już dostępne​

React Hooks są częścią tego wydania, umożliwiając ponowne wykorzystanie logiki stanowej między komponentami. Jest wiele szumu wokół hooków, ale jeśli jeszcze nie słyszeliście, zerknijcie na te świetne materiały:

• Wprowadzenie do Hooks wyjaśnia dlaczego dodajemy Hooki do Reacta.
• Przegląd Hooków to szybkie omówienie wbudowanych Hooków.
• Tworzenie własnych Hooków demonstruje ponowne użycie kodu z niestandardowymi Hookami.
• Zrozumienie React Hooks bada nowe możliwości jakie otwierają Hooki.
• useHooks.com prezentuje społecznościowe przepisy i dema Hooków.

Wypróbujcie je w swoich aplikacjach. Mamy nadzieję, że ponowne wykorzystanie kodu będzie dla Was tak ekscytujące jak dla nas.

📱 Zaktualizowany JSC oznacza wzrost wydajności i wsparcie 64-bit na Androidzie​

React Native używa JSC (JavaScriptCore) do uruchamiania aplikacji. JSC na Androidzie był kilka lat starszy, przez co brakowało wsparcia dla nowoczesnych funkcji JavaScriptu. Co gorsza, wypadał gorzej pod względem wydajności w porównaniu do nowoczesnego JSC na iOS. To wydanie zmienia tę sytuację.

Dzięki wspaniałej pracy @DanielZlotin, @dulmandakh, @gengjiawen, @kmagiera i @kudo JSC nadgonił zaległości. To przynosi wsparcie 64-bitowe, obsługę nowoczesnego JavaScriptu i znaczącą poprawę wydajności. Uznanie za usprawnienie procesu utrzymania, dzięki czemu łatwiej będzie korzystać z przyszłych ulepszeń WebKita. Dziękujemy Software Mansion i Expo za umożliwienie tej pracy.

💨 Szybsze uruchamianie aplikacji dzięki inline requires​

Chcemy pomóc w tworzeniu wydajnych aplikacji React Native domyślnie, przenosząc optymalizacje z Facebooka do społeczności. Zasoby ładują się na żądanie zamiast spowalniać uruchamianie. Ta funkcja nazywa się "inline requires" i pozwala Metro identyfikować komponenty do leniwego ładowania. Największą poprawę zauważą aplikacje z rozbudowaną architekturą komponentów.

Potrzebujemy informacji od społeczności zanim włączymy to domyślnie. Po aktualizacji do 0.59 pojawi się nowy plik metro.config.js; zmieńcie opcje na true i podzielcie się opinią! Przeczytajcie więcej o inline requires w dokumentacji wydajności aby zmierzyć wyniki swojej aplikacji.

🚅 Lean core w toku​

React Native to duży i złożony projekt o skomplikowanym repozytorium. Utrudnia to podejście współtwórcom, testowanie i powoduje nadmiarowe zależności. Lean Core to nasza inicjatywa rozwiązania tych problemów poprzez przenoszenie kodu do osobnych bibliotek. Poprzednie wydania zawierały pierwsze kroki, ale czas na poważne działania.

Możecie zauważyć, że dodatkowe komponenty są teraz oficjalnie przestarzałe. To dobra wiadomość, ponieważ funkcje te mają teraz aktywnych opiekunów. Zwracajcie uwagę na ostrzeżenia i migrujcie do nowych bibliotek, ponieważ te funkcje zostaną usunięte w przyszłych wydaniach. Poniższa tabela wskazuje komponent, jego status i miejsce migracji.

W nadchodzących miesiącach więcej komponentów podąży tą ścieżką ku szczuplejszemu rdzeniowi. Poszukujemy pomocy - dołączcie do omówienia Lean Core.

👩🏽‍💻 Ulepszenia CLI​

Narzędzia wiersza poleceń React Native to punkt wejścia dla deweloperów, ale miały długotrwałe problemy i brak oficjalnego wsparcia. CLI zostało przeniesione do nowego repozytorium, a dedykowana grupa opiekunów już wprowadziła ekscytujące ulepszenia.

Logi są teraz lepiej formatowane. Polecenia uruchamiają się niemal natychmiast - różnica jest od razu widoczna:

🚀 Aktualizacja do 0.59​

Wysłuchaliśmy Waszych uwag dotyczących procesu aktualizacji React Native i pracujemy nad poprawą doświadczeń w przyszłych wydaniach. Do aktualizacji na 0.59 polecamy użyć rn-diff-purge aby sprawdzić zmiany między Waszą wersją a 0.59, następnie ręcznie je zastosować. Po aktualizacji projektu do 0.59, będziecie mogli użyć ulepszonego polecenia react-native upgrade (bazującego na rn-diff-purge!) do aktualizacji na 0.60 i nowsze wersje.

🔨 Zmiany łamiące kompatybilność​

Wsparcie Androida w 0.59 zostało oczyszczone zgodnie z najnowszymi zaleceniami Google, co może powodować problemy w istniejących aplikacjach. Problem może objawiać się awarią podczas działania i komunikatem "You need to use a Theme.AppCompat theme (or descendant) with this activity". Zalecamy aktualizację pliku AndroidManifest.xml, upewniając się że wartość android:theme to motyw AppCompat (np. @style/Theme.AppCompat.Light.NoActionBar).

Polecenie react-native-git-upgrade zostało usunięte w 0.59 na rzecz ulepszonego react-native upgrade.

🤗 Podziękowania​

Wielu nowych współtwórców pomogło w generowaniu kodu natywnego z typów Flow i rozwiązywaniu ostrzeżeń Xcode - to świetny sposób by nauczyć się działania React Native i przyczynić do wspólnego dobra. Dziękujemy! Wypatrujcie podobnych zagadnień w przyszłości.

To tylko niektóre z najważniejszych zmian, ale czeka Was znacznie więcej atrakcji. Pełną listę aktualizacji znajdziecie w dzienniku zmian. Wydanie 0.59 to ogromny krok – nie możemy się doczekać, aż je przetestujecie.

W ciągu najbliższych miesięcy przygotowujemy jeszcze więcej ulepszeń. Śledźcie nasze komunikaty!

Ryan i cały zespół podstawowy React Native

W czwartym kwartale 2018 roku ogłosiliśmy naszą mapę drogową React Native Open Source po podjęciu decyzji o większym zaangażowaniu w społeczność open source React Native.

W pierwszym kamieniu milowym skupiliśmy się na zidentyfikowaniu i ulepszeniu najbardziej widocznych aspektów naszej społeczności. Nasze cele obejmowały: redukcję zaległych pull requestów, zmniejszenie obszaru projektu, identyfikację kluczowych problemów użytkowników oraz ustalenie wytycznych zarządzania społecznością.

W ciągu ostatnich dwóch miesięcy osiągnęliśmy większy postęp, niż się spodziewaliśmy. Czytaj dalej, aby poznać szczegóły:

Pull Requesty​

Aby zbudować zdrową społeczność, musimy szybko reagować na wkłady kodu. W minionych latach zepchnęliśmy na dalszy plan przeglądanie wkładów społeczności, co doprowadziło do nagromadzenia 280 pull requestów (grudzień 2018). W pierwszym kamieniu milowym zmniejszyliśmy liczbę otwartych pull requestów do ~65. Jednocześnie średnia liczba otwieranych pull requestów dziennie wzrosła z 3.5 do 7, co oznacza, że obsłużyliśmy około 600 pull requestów w ciągu ostatnich trzech miesięcy.

Scaliliśmy prawie dwie trzecie i zamknęliśmy jedną trzecią pull requestów. Zamykaliśmy je bez scalania, jeśli były przestarzałe, niskiej jakości lub niepotrzebnie zwiększały obszar projektu. Większość scalonych pull requestów naprawiała błędy, poprawiała zgodność międzyplatformową lub wprowadzała nowe funkcje. Wśród znaczących wkładów znalazły się poprawa bezpieczeństwa typów oraz trwające prace nad wsparciem dla AndroidX.

W Facebooku korzystamy z React Native bezpośrednio z gałęzi master, więc najpierw testujemy wszystkie zmiany, zanim trafią do wydania React Native. Spośród wszystkich scalonych pull requestów tylko sześć spowodowało problemy: cztery dotyczyły wyłącznie rozwoju wewnętrznego, a dwa zostały wychwycone na etapie kandydata do wydania.

Jednym z bardziej widocznych wkładów społeczności był zaktualizowany ekran „RedBox”. To doskonały przykład, jak społeczność czyni doświadczenie deweloperskie bardziej przyjaznym.

Lean Core​

React Native ma obecnie bardzo szeroki obszar z wieloma nieutrzymywanymi abstrakcjami, których rzadko używamy w Facebooku. Pracujemy nad zmniejszeniem tego obszaru, aby uczynić React Native mniejszym i umożliwić społeczności lepszą opiekę nad abstrakcjami, które są w Facebooku głównie nieużywane.

W pierwszym kamieniu milowym poprosiliśmy społeczność o pomoc w projekcie Lean Core. Odzew był przytłaczający i ledwo nadążaliśmy z postępem. Zobacz całą pracę wykonaną w mniej niż miesiąc!

Najbardziej cieszy nas, że opiekunowie zaangażowali się w naprawę długotrwałych problemów, dodawanie testów i wspieranie długo oczekiwanych funkcji. Te moduły otrzymują więcej wsparcia niż kiedykolwiek w ramach React Native, co pokazuje, że to świetny krok dla społeczności. Przykładami takich projektów są WebView, który otrzymał wiele pull requestów od czasu wydzielenia, oraz CLI, które jest teraz utrzymywane przez członków społeczności i otrzymało bardzo potrzebne ulepszenia oraz poprawki.

Główne problemy użytkowników​

W grudniu zapytaliśmy społeczność, co nie podoba im się w React Native. Zebraliśmy odpowiedzi i odpowiedzieliśmy na każdy zgłoszony problem. Na szczęście wiele wyzwań naszej społeczności to również problemy wewnątrz Facebooka. W kolejnym kamieniu milowym planujemy rozwiązać kluczowe z nich.

Jednym z najczęściej wskazywanych problemów było doświadczenie deweloperskie przy aktualizowaniu React Native. Niestety, sami tego nie doświadczamy, ponieważ korzystamy bezpośrednio z gałęzi głównej. Na szczęście członkowie społeczności już podjęli działania:

• Michał Pierzchała z Callstack ulepszył proces aktualizacji wykorzystując rn-diff-purge. Zaktualizowaliśmy też dokumentację usuwając przestarzałe instrukcje.

• Planujemy rekomendować CocoaPods jako domyślne rozwiązanie dla iOS, co zmniejszy chaos w plikach projektu podczas aktualizacji. Ułatwi to instalację i linkowanie modułów innych firm – szczególnie ważne w kontekście Lean Core, gdzie projekty będą domyślnie linkować więcej modułów.

Wydanie wersji 0.59​

Bez pomocy społeczności React Native, zwłaszcza Mike'a Grabowskiego i Lorenzo Sciandry, nie bylibyśmy w stanie publikować wersji. Chcemy ulepszyć proces zarządzania wydaniami:

• Będziemy współpracować ze społecznością przy tworzeniu wpisów na blogu dla każdej głównej wersji

• Będziemy wyświetlać breaking changes bezpośrednio w CLI podczas aktualizacji

• Skrócimy czas publikacji wersji. Badamy możliwości zwiększenia automatyzacji testów i tworzymy ulepszony plan testów manualnych

Wiele z tych planów znajdzie się w nadchodzącym wydaniu React Native 0.59. Wersja 0.59 zawiera React Hooks, 64-bitową wersję JavaScriptCore dla Androida oraz liczne ulepszenia wydajnościowe. Obecnie dostępna jako release candidate, stabilna wersja powinna pojawić się w ciągu dwóch tygodni.

Kolejne kroki​

Przez najbliższe dwa miesiące będziemy utrzymywać tempo w zarządzaniu pull requestami jednocześnie redukując zaległe zgłoszenia na GitHubie. Kontynuujemy zmniejszanie powierzchni projektu poprzez Lean Core i planujemy rozwiązać 5 głównych problemów społeczności. Po finalizacji wytycznych społeczności skupimy się na stronie i dokumentacji.

Z niecierpliwością czekamy na przyjęcie ponad dziesięciu współtwórców w siedzibie Facebooka w Londynie, gdzie będziemy wspólnie pracować nad tymi inicjatywami. Cieszymy się, że korzystasz z React Native i mamy nadzieję, że zauważysz poprawę w 2019 roku. Wrócimy z kolejnymi aktualizacjami za kilka miesięcy, a w międzyczasie będziemy mergować wasze pull requesty! ⚛️✌️

W 2018 roku społeczność React Native wprowadziła szereg zmian w sposobie, w jaki rozwijamy i komunikujemy się na temat React Native. Wierzymy, że za kilka lat spojrzymy wstecz i zobaczymy, że ta zmiana była punktem zwrotnym dla React Native.

Wiele osób jest podekscytowanych przepisaniem architektury React Native, powszechnie znanym jako Fabric. Między innymi naprawi to fundamentalne ograniczenia w architekturze React Native i przygotuje React Native na sukces w przyszłości wraz z JSI i TurboModules.

Największą zmianą w 2018 roku było wzmocnienie społeczności React Native. Od samego początku Facebook zachęcał programistów z całego świata do uczestnictwa w projekcie open source React Native. Od tego czasu pojawiła się grupa kluczowych współtwórców, którzy zajęli się m.in. procesem wydawania nowych wersji.

Ci członkowie podjęli kilka istotnych kroków, aby umożliwić całej społeczności większy wpływ na kształtowanie przyszłości tego projektu, udostępniając następujące zasoby:

react-native-releases 📬​

To repozytorium, utworzone w styczniu, służy podwójnemu celowi: umożliwia wszystkim śledzenie nowych wydań w bardziej współpracujący sposób oraz otwiera dyskusję na temat tego, co powinno znaleźć się w danym wydaniu, dla każdego, kto chciał zasugerować cherry-pick (jak w przypadku 0.57.8 i wszystkich poprzednich wersji).

To było siłą napędową odejścia od miesięcznego cyklu wydawniczego i podejścia "długoterminowego wsparcia" obecnie używanego dla wersji 0.57.x.

Połowa zasług w podjęciu tych decyzji należy do innego repozytorium utworzonego w tym roku:

discussions-and-proposals 🗣​

To repozytorium, utworzone w lipcu, rozwinęło ideę bardziej otwartego środowiska do rozmów na temat React Native. Wcześniej to zapotrzebowanie było obsługiwane przez zgłoszenia z etykietą For Discussion w głównym repozytorium, ale chcieliśmy rozszerzyć tę strategię na podejście RFC, które mają inne biblioteki (np. React).

Ten eksperyment natychmiast znalazł swoje miejsce w cyklu życia React Native. Zespół Facebooka używa teraz społecznościowego procesu RFC, aby dyskutować, co można ulepszyć w React Native, i koordynować działania wokół projektu Lean Core - pośród innych ciekawych dyskusji.

@ReactNativeComm 🐣​

Zdajemy sobie sprawę, że nasze podejście do komunikowania tych działań nie było tak skuteczne, jak byśmy tego chcieli, i w próbie ułatwienia wam śledzenia wszystkiego, co dzieje się w społeczności React Native (od wydań po aktywne dyskusje), utworzyliśmy nowe konto na Twitterze, na którym możecie polegać: @ReactNativeComm.

Jeśli nie jesteście na tej platformie społecznościowej, pamiętajcie, że zawsze możecie obserwować repozytoria przez GitHub; ta funkcja została ulepszona w ciągu ostatnich kilku miesięcy z możliwością otrzymywania powiadomień tylko o wydaniach, więc i tak powinniście rozważyć jej użycie.

Co czeka nas w przyszłości 🎓​

W ciągu ostatnich 7-8 miesięcy kluczowi współtwórcy rozwinęli organizację React Native Community na GitHubie, aby przejąć większą odpowiedzialność za rozwój React Native i poprawić współpracę z Facebookiem. Jednakże zawsze brakowało formalnej struktury, którą podobne projekty mogą mieć na miejscu.

Ta organizacja może stanowić przykład dla całej szerszej społeczności programistów poprzez wprowadzanie zestawu standardów dla wszystkich pakietów/repozytoriów w niej hostowanych, zapewniając jednocześnie wspólną przestrzeń dla opiekunów do wzajemnej pomocy i dostarczania kodu wysokiej jakości spełniającego standardy uzgodnione przez społeczność.

Na początku 2019 roku wprowadzimy w życie ten nowy zestaw wytycznych. Podziel się swoją opinią w dedykowanej dyskusji.

Jesteśmy przekonani, że dzięki tym zmianom społeczność stanie się bardziej współpracująca, tak że gdy osiągniemy wersję 1.0, wszyscy będziemy mogli tworzyć (jeszcze więcej) wspaniałych aplikacji wykorzystując ten wspólny wysiłek 🤗

Mam nadzieję, że jesteś równie podekscytowany przyszłością tej społeczności co my. Z niecierpliwością czekamy na Wasze zaangażowanie - czy to poprzez dyskusje w wymienionych repozytoriach, czy poprzez tworzenie wspaniałego kodu.

Miłego kodowania!

W tym roku zespół React Native skupił się na dużych zmianach architektonicznych. Jak wspomniała Sophie w swoim wpisie o stanie React Native, przygotowaliśmy plan lepszego wsparcia rosnącej społeczności użytkowników i współtwórców React Native poza Facebookiem. Teraz nadszedł czas, aby podzielić się szczegółami naszych prac. Zanim to zrobię, chciałbym przedstawić naszą długoterminową wizję dla React Native w open source.

Nasza wizja dla React Native to...

• Zdrowy repozytorium na GitHubie. Problemy i pull requesty są rozwiązywane w rozsądnym czasie.

  • Zwiększony poziom pokrycia testami.
  • Commity synchronizowane z wewnętrznego repozytorium Facebooka nie powinny łamać testów open source.
  • Większa skala znaczących kontrybucji społeczności.

• Stabilne API ułatwiające integrację z zależnościami open source.

  • Facebook używa tego samego publicznego API co społeczność open source.
  • Wydania React Native zgodne z wersjonowaniem semantycznym.

• Żywy ekosystem. ViewManagery, moduły natywne wysokiej jakości i wsparcie wielu platform utrzymywane przez społeczność.

• Doskonała dokumentacja. Skupienie na pomocy użytkownikom w tworzeniu wysokiej jakości rozwiązań oraz aktualna dokumentacja API.

Zidentyfikowaliśmy następujące obszary kluczowe, które pomogą nam osiągnąć tę wizję.

✂️ Lean Core (Odchudzenie rdzenia)​

Naszym celem jest zmniejszenie obszaru React Native poprzez usunięcie komponentów nierdzewnych i nieużywanych. Przekażemy te komponenty społeczności, aby mogła szybciej się rozwijać. Mniejsza powierzchnia projektu ułatwi zarządzanie kontrybucjami.

WebView to przykład komponentu przekazanego społeczności. Pracujemy nad przepływem pracy, który pozwoli wewnętrznym zespołom na dalsze używanie tych komponentów po usunięciu ich z repozytorium. Zidentyfikowaliśmy dziesiątki kolejnych komponentów, których własność przekażemy społeczności.

🎁 Upublicznienie narzędzi wewnętrznych i 🛠 zaktualizowane narzędzia​

Doświadczenie programistów React Native w zespołach Facebooka może znacznie różnić się od open source. Narzędzia popularne w społeczności open source nie są używane w Facebooku. Czasem istnieją wewnętrzne odpowiedniki osiągające ten sam cel. Zespoły Facebooka przyzwyczaiły się do narzędzi niedostępnych publicznie. Te różnice stanowią wyzwanie przy publikacji naszej nowej architektury.

Zamierzamy opublikować część tych wewnętrznych narzędzi. Poprawimy też wsparcie dla narzędzi popularnych w społeczności open source. Oto niepełna lista projektów, którymi się zajmiemy:

• Upublicznienie JSI i umożliwienie społeczności używania własnych maszyn wirtualnych JavaScript, zastępując obecny JavaScriptCore z pierwszej wersji RN. W kolejnym wpisie wyjaśnimy czym jest JSI, a tymczasem możesz dowiedzieć się więcej z prezentacji Parashurama na React Conf.

• Wsparcie dla 64-bitowych bibliotek na Androidzie.

• Włączenie debugowania w nowej architekturze.

• Poprawa wsparcia dla CocoaPods, Gradle, Maven i nowego systemu budowania Xcode.

✅ Infrastruktura testowa​

Gdy inżynierowie z Facebooka publikują kod, jest on uznawany za bezpieczny do wdrożenia, jeśli przejdzie wszystkie testy. Testy te wykrywają, czy zmiana może potencjalnie uszkodzić którąś z naszych własnych powierzchni React Native. Istnieją jednak różnice w sposobie używania React Native przez Facebooka. Pozwoliło to nam nieświadomie wprowadzać błędy do wersji open source.

Wzmocnimy nasze testy wewnętrzne, aby działały w środowisku jak najbardziej zbliżonym do open source. To pomoże zapobiec przedostawaniu się kodu, który łamie te testy, do wersji publicznej. Pracujemy także nad infrastrukturą umożliwiającą lepsze testowanie głównego repozytorium na GitHubie, co pozwoli przyszłym pull requestom łatwiej zawierać testy.

Połączone z redukcją powierzchni kodu, pozwoli to współtwórcom bezpieczniej i szybciej scalać pull requesty.

📜 Publiczny interfejs API​

Facebook będzie korzystał z React Native poprzez publiczny interfejs API, tak samo jak społeczność open source, aby zmniejszyć ryzyko niezamierzonych zmian łamiących kompatybilność. Rozpoczęliśmy konwersję wewnętrznych wywołań w tym celu. Naszym celem jest ustabilizowanie publicznego API, co umożliwi przyjęcie wersjonowania semantycznego w wersji 1.0.

📣 Komunikacja​

React Native to jeden z najpopularniejszych projektów open source na GitHubie pod względem liczby współtwórców. To nas bardzo cieszy i chcemy to podtrzymać. Będziemy kontynuować inicjatywy angażujące społeczność, takie jak zwiększona przejrzystość i otwarte dyskusje. Dokumentacja jest często pierwszym kontaktem nowych osób z React Native, jednak nie była dotąd priorytetem. Chcemy to naprawić, zaczynając od przywrócenia automatycznie generowanej dokumentacji API, tworzenia treści skupionych na budowaniu jakościowych doświadczeń użytkownika oraz ulepszania naszych informacji o wydaniach.

Harmonogram​

Planujemy wdrażać te projekty w ciągu najbliższego roku. Niektóre inicjatywy są już w toku, jak JSI, które trafiło już do open source. Inne, jak redukcja powierzchni kodu, zajmą nieco więcej czasu. Dołożymy starań, by na bieżąco informować społeczność o postępach. Zapraszamy do udziału w repozytorium Dyskusje i Propozycje – inicjatywie społeczności React Native, która doprowadziła do powstania kilku projektów omówionych w tym planie.

Od dłuższego czasu Apple odradza używanie UIWebView na rzecz WKWebView. W iOS 12, który zostanie wydany w nadchodzących miesiącach, UIWebView zostanie oficjalnie oznaczony jako przestarzały. Implementacja WebView dla iOS w React Native w dużej mierze opiera się na klasie UIWebView. Dlatego w świetle tych zmian stworzyliśmy nowy natywny backend dla iOS dla komponentu WebView w React Native, który wykorzystuje WKWebView.

Końcowe zmiany zostały wprowadzone w tym commicie i będą dostępne w wersji 0.57.

Aby skorzystać z tej nowej implementacji, użyj właściwości useWebKit:

<WebView
  useWebKit={true}
  source={{url: 'https://www.google.com'}}
/>

Ulepszenia​

UIWebView nie posiadał prawidłowego sposobu na ułatwienie komunikacji między JavaScript działającym w WebView a React Native. Gdy wiadomości były wysyłane z WebView, polegaliśmy na obejściu, aby dostarczyć je do React Native. W skrócie, kodowaliśmy dane wiadomości w adresie URL ze specjalnym schematem i przekierowywaliśmy WebView pod ten adres. Po stronie natywnej przechwytywaliśmy i anulowaliśmy to przekierowanie, przetwarzaliśmy dane z adresu URL i w końcu wywoływaliśmy React Native. Ta implementacja była podatna na błędy i niebezpieczna. Z przyjemnością ogłaszam, że wykorzystaliśmy funkcje WKWebView, aby całkowicie ją zastąpić.

Inne zalety WKWebView w porównaniu z UIWebView to szybsze wykonywanie kodu JavaScript oraz architektura wieloprocesowa. Więcej szczegółów znajdziesz w WWDC 2014.

Ograniczenia​

Jeśli twoje komponenty używają poniższych właściwości, możesz napotkać problemy podczas przełączania się na WKWebView. Na razie sugerujemy unikanie używania tych właściwości:

Niespójne zachowanie:

automaticallyAdjustContentInsets i contentInsets (commit)

Gdy dodasz contentInsets do WKWebView, nie zmienia to viewportu WKWebView. Viewport pozostaje tej samej wielkości co ramka. W przypadku UIWebView rozmiar viewportu faktycznie się zmienia (zmniejsza się, jeśli contentInsets są dodatnie).

backgroundColor (commit)

W nowej implementacji WebView dla iOS istnieje możliwość, że kolor tła będzie migać, jeśli użyjesz tej właściwości. Ponadto WKWebView renderuje przezroczyste tła inaczej niż UIWebview. Więcej szczegółów znajdziesz w opisie commita.

Nieobsługiwane:

scalesPageToFit (commit)

WKWebView nie obsługiwał właściwości scalesPageToFit, więc nie mogliśmy zaimplementować tego w komponencie WebView React Native.

Motywacja​

Wraz z postępem technologicznym i rosnącym znaczeniem aplikacji mobilnych w codziennym życiu, rośnie także potrzeba tworzenia dostępnych aplikacji.

Ograniczone API Dostępności React Native zawsze było dużym problemem dla developerów, dlatego wprowadziliśmy kilka aktualizacji, aby ułatwić tworzenie inkluzywnych aplikacji mobilnych.

Problemy z istniejącym API​

Problem pierwszy: Dwie zupełnie różne, a jednak podobne właściwości - accessibilityComponentType (Android) i accessibilityTraits (iOS)​

accessibilityComponentType i accessibilityTraits to dwie właściwości służące do informowania TalkBack na Androidzie i VoiceOver na iOS, z jakim elementem interfejsu użytkownik ma do czynienia. Największe problemy z tymi właściwościami to:

1. To dwie różne właściwości o różnych metodach użycia, ale tym samym celu. W poprzednim API były to osobne właściwości (po jednej na platformę), co było nie tylko niewygodne, ale też mylące dla wielu developerów. accessibilityTraits na iOS pozwala na 17 różnych wartości, podczas gdy accessibilityComponentType na Androidzie tylko na 4. Co więcej, wartości w większości się nie pokrywały. Nawet typy danych wejściowych różnią się: accessibilityTraits akceptuje tablicę cech lub pojedynczą cechę, podczas gdy accessibilityComponentType tylko pojedynczą wartość.

2. Bardzo ograniczona funkcjonalność na Androidzie. Przy starej właściwości TalkBack rozpoznawał tylko elementy: "button", "radiobutton_checked" i "radiobutton_unchecked".

Problem drugi: Brak podpowiedzi dostępności​

Podpowiedzi dostępności pomagają użytkownikom TalkBack i VoiceOver zrozumieć, co się stanie po wykonaniu akcji na elemencie dostępności, gdy nie jest to oczywiste na podstawie samej etykiety. Te podpowiedzi można włączać i wyłączać w panelu ustawień. Poprzednio API React Native w ogóle nie obsługiwało podpowiedzi dostępności.

Problem trzeci: Ignorowanie odwróconych kolorów​

Niektórzy użytkownicy z wadami wzroku używają odwróconych kolorów w telefonach, aby uzyskać większy kontrast ekranu. Apple udostępniło API dla iOS, które pozwala developerom ignorować określone widoki. Dzięki temu obrazy i filmy nie są zniekształcane, gdy użytkownik ma włączone odwrócone kolory. To API nie jest obecnie obsługiwane przez React Native.

Projekt nowego API​

Rozwiązanie pierwsze: Połączenie accessibilityComponentType (Android) i accessibilityTraits (iOS)​

Aby rozwiązać problem rozbieżności między accessibilityComponentType a accessibilityTraits, postanowiliśmy połączyć je w jedną właściwość. To rozwiązanie miało sens, ponieważ technicznie pełnią tę samą funkcję, a ich połączenie zwalnia developerów z konieczności martwienia się o specyfikę platformy przy budowaniu funkcji dostępności.

Tło

W iOS UIAccessibilityTraits to właściwość, którą można ustawić na dowolnym obiekcie NSObject. Każda z 17 cech przekazanych przez właściwość JavaScript do natywnych jest mapowana na element UIAccessibilityTraits w Objective-C. Cechy są reprezentowane przez wartości typu long int, a każda ustawiona cecha jest łączona operatorem OR.

W Androidzie jednak AccessibilityComponentType to koncept wymyślony przez React Native, który nie ma bezpośredniego odpowiednika we właściwościach Androida. Dostępność jest obsługiwana przez delegata dostępności. Każdy widok ma domyślnego delegata. Aby dostosować dowolne akcje dostępności, należy utworzyć nowego delegata, nadpisać konkretne metody, które chcemy dostosować, a następnie ustawić delegata dostępności dla obsługiwanego widoku. Gdy developer ustawiał AccessibilityComponentType, natywny kod tworzył nowego delegata na podstawie przekazanego komponentu i przypisywał go do widoku.

Wprowadzone zmiany

Dla naszej nowej właściwości chcieliśmy stworzyć superset obu istniejących właściwości. Zdecydowaliśmy się wzorować nową właściwość głównie na istniejącej accessibilityTraits, ponieważ accessibilityTraits ma znacznie więcej wartości. Funkcjonalność dla Androida zostanie zapewniona poprzez modyfikację Delegata Dostępności.

Istnieje 17 wartości UIAccessibilityTraits, które można ustawić dla accessibilityTraits w iOS. Jednak nie uwzględniliśmy wszystkich jako możliwych wartości dla nowej właściwości. Dzieje się tak, ponieważ efekt ustawienia niektórych z tych cech jest mało znany, a wiele wartości praktycznie nigdy nie jest używanych.

Wartości UIAccessibilityTraits generalnie pełniły jedną z dwóch funkcji: opisywały rolę elementu interfejsu lub jego stan. W większości obserwowanych przypadków używano jednej wartości reprezentującej rolę w połączeniu z "state selected", "state disabled" lub obydwoma. Dlatego zdecydowaliśmy się stworzyć dwie nowe właściwości dostępności: accessibilityRole i accessibilityState.

accessibilityRole

Nowa właściwość accessibilityRole służy do informowania TalkBacka lub Voiceovera o roli elementu interfejsu. Może przyjmować jedną z następujących wartości:

• none

• button

• link

• search

• image

• keyboardkey

• text

• adjustable

• header

• summary

• imagebutton

Ta właściwość pozwala na przekazanie tylko jednej wartości, ponieważ elementy interfejsu generalnie nie pełnią logicznie więcej niż jednej z tych ról. Wyjątkiem jest połączenie obrazu i przycisku, dlatego dodaliśmy rolę imagebutton będącą kombinacją obu.

accessibilityStates

Nowa właściwość accessibilityStates służy do informowania TalkBacka lub Voiceovera o stanie elementu interfejsu. Przyjmuje tablicę zawierającą jedną lub obie z następujących wartości:

• selected

• disabled

Rozwiązanie drugie: Dodawanie podpowiedzi dostępności​

W tym celu dodaliśmy nową właściwość accessibilityHint. Jej ustawienie umożliwi TalkBackowi lub Voiceoverowi odczytanie podpowiedzi użytkownikom.

accessibilityHint

Ta właściwość przyjmuje podpowiedź dostępności w formie ciągu znaków (String) do odczytania.

W iOS ustawienie tej właściwości konfiguruje natywną właściwość AccessibilityHint widoku. Podpowiedź będzie odczytywana przez Voiceover, jeśli podpowiedzi dostępności są włączone w ustawieniach iPhone'a.

W Androidzie ustawienie tej właściwości dołącza wartość podpowiedzi na końcu etykiety dostępności. Zaleta tego rozwiązania polega na naśladowaniu zachowania podpowiedzi w iOS, ale wadą jest to, że w Androidzie nie można wyłączyć tych podpowiedzi w ustawieniach tak jak w iOS.

Podjęliśmy tę decyzję dla Androida, ponieważ podpowiedzi dostępności zwykle odpowiadają konkretnej akcji (np. kliknięciu) i chcieliśmy zachować spójne zachowanie między platformami.

Rozwiązanie problemu trzeciego​

accessibilityIgnoresInvertColors

Udostępniliśmy w JavaScript interfejs API Apple AccessibilityIgnoresInvertColors. Teraz gdy masz widok, którego kolory nie powinny być inwertowane (np. obraz), możesz ustawić tę właściwość na true, a kolory nie zostaną odwrócone.

Nowe zastosowanie​

Te nowe właściwości będą dostępne w wydaniu React Native 0.57.

Jak przeprowadzić aktualizację​

Jeśli obecnie używasz accessibilityComponentType i accessibilityTraits, oto kroki, które możesz podjąć, aby przejść na nowe właściwości.

1. Używanie jscodeshift​

Najprostsze przypadki użycia można zastąpić, uruchamiając skrypt jscodeshift.

Ten skrypt zastępuje następujące przypadki:

accessibilityTraits=“trait”
accessibilityTraits={[“trait”]}

Zastąpiono przez

accessibilityRole= “trait”

Ten skrypt usuwa również wystąpienia AccessibilityComponentType (zakładając, że wszędzie tam, gdzie ustawiono AccessibilityComponentType, ustawiono również AccessibilityTraits).

2. Używanie ręcznego codemodu​

W przypadkach, w których używano AccessibilityTraits bez odpowiedniej wartości dla AccessibilityRole, oraz w przypadkach, gdy do AccessibilityTraits przekazywano wiele cech, konieczne było wykonanie ręcznego codemodu.

Ogólnie rzecz biorąc,

accessibilityTraits= {[“button”, “selected”]}

byłyby ręcznie zastąpione przez

accessibilityRole=“button”
accessibilityStates={[“selected”]}

Te właściwości są już używane w bazie kodu Facebooka. Codemod dla Facebooka był zaskakująco prosty. Skrypt jscodeshift naprawił około połowy naszych przypadków, a druga połowa została naprawiona ręcznie. Cały proces trwał mniej niż kilka godzin.

Mamy nadzieję, że zaktualizowane API okaże się przydatne! I prosimy, kontynuujcie tworzenie dostępnych aplikacji! #inclusion

Długo wyczekiwana wersja 0.56 React Native jest już dostępna 🎉. W tym poście na blogu przedstawiamy niektóre zmiany wprowadzone w tym wydaniu. Chcemy też wyjaśnić, czym zajmowaliśmy się od marca.

Dylemat zmian łamiących kompatybilność, czyli "kiedy wydać?"​

Przewodnik dla współtwórców opisuje proces integracji, przez który przechodzą wszystkie zmiany w React Native. Projekt składa się z wielu różnych narzędzi, wymagających koordynacji i stałego wsparcia, aby wszystko działało poprawnie. Dodaj do tego żywą społeczność open source, która przyczynia się do projektu, a zrozumiesz ogromną skalę tego przedsięwzięcia.

Przy imponującym przyjęciu React Native, zmiany łamiące kompatybilność muszą być wprowadzane z dużą ostrożnością, a proces nie jest tak płynny, jakbyśmy chcieli. Podjęto decyzję o pominięciu wydań z kwietnia i maja, aby umożliwić zespołowi głównemu integrację i testowanie nowego zestawu zmian łamiących kompatybilność. Po drodze wykorzystano dedykowane kanały komunikacji ze społecznością, aby zapewnić, że wydanie z czerwca 2018 (0.56.0) będzie jak najłatwiejsze do przyjęcia dla tych, którzy cierpliwie czekali na stabilną wersję.

Czy 0.56.0 jest idealne? Nie, jak każdy inny kawałek oprogramowania: ale osiągnęliśmy punkt, w którym kompromis między "czekaniem na większą stabilność" a "testowanie dało pozytywne wyniki, więc możemy iść do przodu" sprawił, że czujemy się gotowi do wydania. Ponadto wiemy o kilku problemach nie rozwiązanych w końcowym wydaniu 0.56.0. Większość programistów nie powinna mieć problemów z aktualizacją do 0.56.0. Dla tych, których blokują wspomniane problemy, mamy nadzieję zobaczyć was w naszych dyskusjach i z niecierpliwością czekamy na współpracę z wami nad rozwiązaniem tych kwestii.

Możecie uznać 0.56.0 za fundamentalny element budujący bardziej stabilny framework: minie prawdopodobnie tydzień lub dwa powszechnego użytkowania, zanim wszystkie skrajne przypadki zostaną wygładzone, ale doprowadzi to do jeszcze lepszego wydania z lipca 2018 (0.57.0).

Chcielibyśmy zakończyć tę sekcję, dziękując wszystkim 67 współtwórcom, którzy pracowali nad łącznie 818 commitami (!), co pomoże uczynić wasze aplikacje jeszcze lepszymi 👏.

A teraz, bez zbędnych ceregieli...

Najważniejsze zmiany​

Babel 7​

Jak zapewne wiecie, narzędzie transpilujące, które pozwala nam wszystkim korzystać z najnowszych i najlepszych funkcji JavaScriptu, Babel, przenosi się wkrótce do wersji 7. Ponieważ ta nowa wersja wprowadza ważne zmiany, uznaliśmy, że teraz jest dobry moment na aktualizację, umożliwiając Metro wykorzystanie jego ulepszeń.

Jeśli napotkacie problemy podczas aktualizacji, zapoznajcie się z odpowiednią sekcją dokumentacji.

Modernizacja wsparcia dla Androida​

Na Androida zmieniło się wiele wokół narzędzi. Zaktualizowaliśmy do Gradle 3.5, Android SDK 26, Fresco do 1.9.0 oraz OkHttp do 3.10.0, a nawet cel NDK do API 16. Te zmiany powinny przejść bezproblemowo i przyspieszyć budowanie. Co ważniejsze, pomogą spełnić nowe wymagania Sklepu Play, które wchodzą w życie w przyszłym miesiącu.

W związku z tym szczególnie dziękujemy Dulmandakh za liczne PR-y, które to umożliwiły 👏.

W tym kierunku trzeba jeszcze podjąć pewne kroki, a przyszłe plany i dyskusje o aktualizacji wsparcia dla Androida możecie śledzić w dedykowanym wątku (oraz w osobnym dotyczącym JSC).

Nowy Node, Xcode, React i Flow – ach, co za różnorodność!​

Node 8 stał się teraz standardem dla React Native. Już wcześniej był testowany, ale postawiliśmy na niego pełną parą, gdy Node 6 wszedł w tryb utrzymania. React również zaktualizowaliśmy do wersji 16.4, która przynosi mnóstwo poprawek.

Wycofujemy wsparcie dla iOS 8, ustawiając iOS 9 jako najstarszą obsługiwaną wersję. Nie przewidujemy problemów, ponieważ każde urządzenie z iOS 8 można zaktualizować do iOS 9. Ta zmiana pozwoliła nam usunąć rzadko używany kod obejść dla starszych urządzeń z iOS 8.

Łańcuch narzędzi CI został zaktualizowany do Xcode 9.4, co zapewnia uruchamianie testów iOS na najnowszych narzędziach deweloperskich Apple.

Zaktualizowaliśmy do Flow 0.75 dla nowego formatu błędów, cenionego przez wielu deweloperów. Dodaliśmy też typy dla wielu kolejnych komponentów. Jeśli jeszcze nie wymuszasz typowania statycznego, rozważ użycie Flow do wykrywania problemów podczas kodowania zamiast w runtime.

I wiele innych rzeczy...​

Na przykład YellowBox został zastąpiony nową implementacją znacznie ułatwiającą debugowanie.

Pełną listę zmian znajdziesz w changelogu. Pamiętaj też o sprawdzeniu przewodnika aktualizacji przed migracją do nowej wersji.

Na koniec: od tego tygodnia zespół React Native wznawia comiesięczne spotkania. Będziemy na bieżąco informować o poruszanych tematach i uwzględniać wasze opinie w przyszłych dyskusjach.

Miłego kodowania wszystkim!

Lorenzo, Ryan i cały zespół React Native

PS: jak zawsze, przypominamy że React Native nadal ma wersję 0.x ze względu na wiele trwających zmian - więc pamiętajcie przy aktualizacji, że coś może nadal się wywrócić lub nie działać. Pomagajcie sobie nawzajem przy zgłaszaniu issue i wysyłaniu PR-ów - i pamiętajcie o przestrzeganiu Kodeksu Postępowania: po drugiej stronie ekranu zawsze stoi człowiek.

Minęło trochę czasu od naszego ostatniego raportu o stanie React Native.

W Facebooku używamy React Native bardziej niż kiedykolwiek w wielu ważnych projektach. Jednym z naszych najpopularniejszych produktów jest Marketplace – jedna z głównych zakładek w naszej aplikacji, z której korzysta 800 milionów osób miesięcznie. Od momentu powstania w 2015 roku cały Marketplace został zbudowany w React Native, obejmując ponad sto pełnoekranowych widoków w różnych częściach aplikacji.

React Native wykorzystujemy także w wielu nowych sekcjach aplikacji. Jeśli oglądaliście zeszłomiesięczny keynote F8, rozpoznacie funkcje takie jak Krwiodawstwo, Reagowanie na kryzysy, Skróty prywatności i Kontrole zdrowia – wszystkie niedawno wprowadzone i zbudowane w React Native. Projekty poza główną aplikacją Facebooka również korzystają z React Native. Nowe gogle VR Oculus Go zawierają aplikację mobilną towarzyszącą w całości zbudowaną w React Native, nie wspominając już o React VR napędzającym wiele funkcji w samych goglach.

Naturalnie korzystamy też z wielu innych technologii do budowania naszych aplikacji. Litho i ComponentKit to dwie biblioteki, których szeroko używamy; obie zapewniają API komponentów podobne do Reacta do budowania natywnych ekranów. React Native nigdy nie miał zastąpić wszystkich innych technologii – skupiamy się na ulepszaniu samego React Native, ale cieszymy się, gdy inne zespoły zapożyczają nasze pomysły, jak wprowadzenie natychmiastowego przeładowania do kodu niebędącego JavaScriptem.

Architektura​

Gdy w 2013 roku rozpoczynaliśmy projekt React Native, zaprojektowaliśmy go z pojedynczym "mostem" między JavaScriptem a kodem natywnym, który jest asynchroniczny, możliwy do serializacji i przetwarzany wsadowo. Tak jak React DOM przekształca aktualizacje stanu w imperatywne wywołania API DOM typu document.createElement(attrs) i .appendChild(), tak React Native został zaprojektowany do zwracania pojedynczej wiadomości JSON listującej mutacje do wykonania, jak [["createView", attrs], ["manageChildren", ...]]. Zaprojektowaliśmy cały system tak, by nigdy nie polegał na synchronicznej odpowiedzi i by zapewnić pełną serializowalność całej listy do JSONa i z powrotem. Zrobiliśmy to dla elastyczności: na tej architekturze zbudowaliśmy narzędzia takie jak debugowanie w Chrome, które asynchronicznie wykonuje cały kod JavaScript przez połączenie WebSocket.

Przez ostatnie 5 lat odkryliśmy, że te początkowe założenia utrudniają implementację niektórych funkcji. Asynchroniczny most uniemożliwia bezpośrednią integrację logiki JavaScript z wieloma natywnymi API oczekującymi synchronicznych odpowiedzi. Wsadowe przetwarzanie wywołań natywnych utrudnia wywoływanie z aplikacji React Native funkcji zaimplementowanych natywnie. A serializowalny most oznacza niepotrzebne kopiowanie zamiast bezpośredniego współdzielenia pamięci między obu światami. Dla aplikacji całkowicie zbudowanych w React Native te ograniczenia są zwykle akceptowalne. Ale dla aplikacji z złożoną integracją między React Native a istniejącym kodem są frustrujące.

Pracujemy nad dużą przebudową architektury React Native, aby framework był bardziej elastyczny i lepiej integrował się z natywną infrastrukturą w hybrydowych aplikacjach JavaScript/natywnych. W tym projekcie zastosujemy wiedzę zdobytą przez ostatnie 5 lat i stopniowo przejdziemy do nowocześniejszej architektury. Przepisujemy wiele wewnętrznych elementów React Native, ale większość zmian odbywa się pod maską: istniejące aplikacje React Native będą działać z niewielkimi modyfikacjami lub bez nich.

Aby React Native był lżejszy i lepiej integrował się z istniejącymi natywnymi aplikacjami, ta rearchitektura wprowadza trzy główne wewnętrzne zmiany. Po pierwsze, zmieniamy model wątkowości. Zamiast wymagać od każdej aktualizacji UI pracy na trzech różnych wątkach, będzie możliwe synchroniczne wywoływanie JavaScriptu z dowolnego wątku dla wysokopriorytetowych aktualizacji, przy jednoczesnym utrzymaniu niskopriorytetowych zadań poza wątkiem głównym dla zachowania responsywności. Po drugie, włączamy możliwości async rendering do React Native, co umożliwi wielopoziomowe priorytety renderowania i uprości obsługę asynchronicznych danych. Wreszcie, upraszczamy nasz mostek, aby był szybszy i lżejszy; bezpośrednie wywołania między natywnym kodem a JavaScriptem są bardziej wydajne i ułatwią budowę narzędzi debugujących takich jak ślady stosu międzyjęzykowego.

Po wprowadzeniu tych zmian możliwe będą ściślejsze integracje. Obecnie włączenie natywnej nawigacji, obsługi gestów czy komponentów takich jak UICollectionView i RecyclerView bez skomplikowanych obejść jest niemożliwe. Po zmianach w modelu wątkowości tworzenie takich funkcji stanie się proste.

Udostępnimy więcej szczegółów na temat tej pracy później w tym roku, gdy będzie bliżej ukończenia.

Społeczność​

Oprócz wewnętrznej społeczności w Facebooku, cieszymy się, że na zewnątrz istnieje prężna społeczność użytkowników i współtwórców React Native. Chcemy lepiej wspierać społeczność React Native, zarówno lepiej służąc użytkownikom, jak i ułatwiając współtworzenie projektu.

Tak jak nasze zmiany architektoniczne pomogą React Native czyściej współdziałać z inną natywną infrastrukturą, React Native powinien być szczuplejszy po stronie JavaScriptu, aby lepiej pasować do ekosystemu JavaScript – w tym umożliwiając wymianę maszyny wirtualnej i bundlera. Wiemy, że tempo zmian łamiących kompatybilność może być trudne do nadążenia, więc chcemy znaleźć sposoby na rzadsze wydawanie wersji głównych. Wreszcie, wiemy że niektóre zespoły poszukują bardziej dogłębnej dokumentacji w tematach takich jak optymalizacja uruchamiania, gdzie nasza ekspertyza nie została jeszcze spisana. Spodziewajcie się takich zmian w nadchodzącym roku.

Jeśli używasz React Native, jesteś częścią naszej społeczności – dziel się z nami swoimi przemyśleniami, jak możemy ulepszyć React Native dla Ciebie.

React Native to tylko jedno z narzędzi w zestawie developera mobilnego, ale wierzymy w nie mocno – i ulepszamy je każdego dnia, z ponad 2500 commitami w ostatnim roku od 500+ współtwórców.