Podsumowanie React Native Core Contributor Summit 2024
Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt. Znalazłeś błąd? Zgłoś problem →
Co roku kluczowi współtwórcy społeczności React Native spotykają się z zespołem React Native, by wspólnie kształtować przyszłość tego projektu.
Rok temu nie było inaczej — z jednym drobnym wyjątkiem. Zwykle spotykamy się dzień przed konferencją React Universe Conf (dawniej React Native EU) w siedzibie Callstack we Wrocławiu. W 2024 roku, wyciągając wnioski z poprzednich doświadczeń, zorganizowaliśmy Szczyt przez dwa kolejne dni, by mieć więcej swobodnego czasu na wspólne dyskusje.
Ta coroczna tradycja stała się cenną okazją dla współtwórców do dzielenia się spostrzeżeniami i zgłaszania uwag, a dla zespołu podstawowego — do prezentacji planów i zbierania feedbacku od kluczowych uczestników ekosystemu React Native, w tym firm partnerskich, autorów bibliotek i przyjaciół projektu.
Podzieliliśmy Szczyt na dwie ścieżki tematyczne:
W tym wpisie blogowym chcielibyśmy pokazać wam efekty tych spotkań.
Wydania
Dyskutowaliśmy intensywnie o procesie wydawniczym React Native. Zespół podstawowy docenia wartość zaangażowania współtwórców spoza Meta w wydania i podkreśla znaczenie codziennych wydań (nightly releases), które są szczególnie przydatne dla platform spoza głównego drzewa, takich jak React Native visionOS, twórców bibliotek (np. Reanimated) oraz frameworków (np. Expo). Dyskutowaliśmy o częstotliwości wydań — część osób opowiadała się za częstszymi wydaniami, aby szybciej dostarczać poprawki, podczas gdy inni wyrażali obawy dotyczące wpływu na biblioteki zewnętrzne i wysiłek związany z aktualizacjami.
Wspólnie szukaliśmy też sposobów na redukcję niezamierzonych zmian łamiących kompatybilność oraz poprawę komunikacji o zgodności między React Native a zależnościami zewnętrznymi.
Ta sesja pokazała, jak złożone jest zarządzanie wydaniami React Native i jak delikatny to temat, biorąc pod uwagę wszystkie różne części ekosystemu, które trzeba uwzględnić.
Co dalej po Nowej Architekturze?
Skoro Nowa Architektura została wydana jako stabilna, dyskutowaliśmy o tym, na czym powinniśmy się skupić dalej. Co może być kolejnym przełomowym krokiem? Tematy koncentrowały się wokół:
-
Kompatybilność z webem – podsumowane w dyskusji o kierunku projektu React Strict DOM, który powinien być traktowany jako tymczasowe rozwiązanie polifillowe, podczas gdy zespół Xplat implementuje właściwą funkcjonalność cross-platform w rdzeń React Native.
-
Stabilizacja podstawowego API – okazało się, że potrzebujemy większego konsensusu co to oznacza dla twórców aplikacji, autorów bibliotek i platform spoza głównego drzewa. Np. może być konieczne wyodrębnienie logiki specyficznej dla platform iOS i Androida ze współdzielonej bazy kodu C++. Część tego zagadnienia została poruszona w dyskusji o LeanCore 2.0.
-
Obsługa starej architektury – zgodnie z oczekiwaniami, zespół potwierdził, że nowe funkcje Reacta 19 oparte na współbieżnym renderowaniu nie będą działać w starej architekturze. Nowe funkcje są przeznaczone głównie dla nowej architektury. Ze względu na problemy w harmonogramie wydania Reacta 19 wciąż nie jest jasne, gdzie przebiegać będzie granica funkcjonalności wspieranej przez obie architektury.
-
Biblioteki stron trzecich dla React Native – obecnie autorzy bibliotek mogą używać TurboModules, ExpoModules, a ostatnio NitroModules, aby osiągnąć ten sam cel połączenia funkcjonalności natywnej platformy. Potrzebujemy lepszej dokumentacji, jak robić to dobrze.
-
Dokumentacja brownfield – w czasie szczytu oficjalna dokumentacja integracji React Native z natywnymi aplikacjami była mocno przestarzała. Od tego czasu zespół opracował aktualne i prostsze dokumenty dla Androida i iOS.
-
Tree-shaking dla Metro web – podstawowy zespół Metro jest otwarty na scalenie prac zespołu Expo w tym obszarze.
Web APIs dla Native Modules
Ta sesja poświęcona była RFC Microsoftu dotyczącemu wprowadzenia podzbioru Web API do React Native. Celem jest zwiększenie skalowalności React Native i przyciągnięcie większej liczby programistów webowych poprzez wykorzystanie znanych interfejsów API, otwierając dostęp do bogactwa istniejących otwartych bibliotek webowych bez natywnego wsparcia React Native.
Standaryzacja specyfikacji Web API jest nie tylko korzystna, ale wręcz niezbędna dla rozwoju React Native i świetnie współgra z naszą wizją Many Platforms oraz projektem react-strict-dom. Sieć oferuje ujednolicony interfejs poprzez swoje specyfikacje, czego brakuje obecnie modułom społeczności React Native. Microsoft zidentyfikował około 200 kluczowych Web API, które można najpierw wdrożyć dla obsługiwanych platform: iOS, Androida, Windows i macOS.
Zachęcamy twórców bibliotek, aby dostosowywali swoje API do specyfikacji webowych, gdy tylko jest to możliwe, ponieważ ta standaryzacja poprawi przenośność kodu i doświadczenia programistów na różnych platformach.
Choć propozycja wydaje się korzystna dla przyszłości React Native, wciąż burzymy głowy nad kolejnymi krokami. Jedną z obaw jest zarządzanie interfejsami API i kwestia, czy powinny znajdować się w osobnym repozytorium niż implementacje platformowe. Inna dotyczy odstępstw od oficjalnej specyfikacji w przypadku, gdy konkretna platforma pozwala na zachowania nieokreślone przez W3C. Musielibyśmy też rozwiązać problem niepotrzebnego dołączania modułów, np. za pomocą wtyczki Babel. Nie wspominając już o tym, że zakres tej inicjatywy jest dość szeroki.
Podsumowanie sesji potwierdziło dwa kluczowe punkty: Po pierwsze, istnieje silna zgodność w społeczności React Native co do przyjmowania specyfikacji kompatybilnych z webem tam, gdzie to możliwe. Po drugie, musimy opracować jasną strategię techniczną utrzymywania tych implementacji Web API dla różnych platform. Microsoft wraz z Callstack mógłby udoskonalić oryginalne RFC i stworzyć implementację proof of concept dla mniejszej liczby API jako inicjatywę społeczności. To podejście iteracyjne pomoże zweryfikować projekt i doświadczenia deweloperów przed rozszerzeniem zakresu.
LeanCore 2.0
W 2019 roku zespół React Native rozpoczął inicjatywę Lean Core. Celem było zmniejszenie obszaru podstawowego React Native poprzez redukcję przestarzałych i legacyjnych API oraz komponentów. Od tego czasu komponenty React Native i interfejsy API są długo przeterminowane na kolejną rundę porządków.
Dziś wiele komponentów nie jest aktywnie utrzymywanych, gdyż istnieją lepsze alternatywy społecznościowe. Dodatkowo niektóre komponenty mają duplikaty, które powinny zostać skonsolidowane dla lepszej utrzymywalności.
Po stronie API, wiele interfejsów w warstwie JS jest powiązanych z implementacjami natywnymi iOS i Androida, zamiast być prawdziwie agnostyczne platformowo. Na przykład w Pressable mamy właściwości jak android_disableSound i android_ripple. Idealnie, komponenty React Native powinny mieć minimalną możliwą powierzchnię API niezwiązaną z żadną konkretną platformą.
W miarę jak platformy Out-of-Tree zyskują popularność i są coraz szerzej przyjmowane w ekosystemie, potrzebna jest ścieżka redukcji powierzchni komponentów i API w rdzeniu React Native. Zmniejszyłoby to obciążenie podstawowego zespołu React Native i ułatwiło utrzymywanie aktualności platformom Out-of-Tree oraz twórcom bibliotek.
Dodatkową korzyścią jest ułatwienie początkującym programistom wdrożenia React Native, dzięki mniejszej liczbie zduplikowanych komponentów i "pułapek" do nauki. Tam, gdzie istnieją lepsze alternatywy społecznościowe, programiści mogą być kierowani i zachęcani do korzystania z nich.
Podczas sesji omówiliśmy:
-
Ogólne motywacje stojące za Lean Core oraz korzyści dla zaangażowanych stron (programistów, opiekunów bibliotek, Meta)
-
Zagregowany przegląd komponentów używanych w rzeczywistych produkcyjnych aplikacjach React Native
-
Kryteria określające, które elementy kwalifikują się do usunięcia z rdzenia
-
Szczegółowy plan wdrożenia Lean Core 2.0 zawierający:
- Proces deprecjacji wysokiego poziomu
- Obsługę przypadków, gdzie Meta używa wewnętrznie komponentów mających lepsze alternatywy społecznościowe
Jako kolejny krok grupa kluczowych współtwórców zajmie się zbieraniem dodatkowej telemetrii i danych, oceną alternatyw społecznościowych oraz przygotowaniem RFC szczegółowo opisującego proponowane zmiany.
Nitro Modules - Odblokowywanie komponentów widoku poprzez eksponowanie właściwości jako jsi::Values
Marc Rousavy niedawno przedstawił Nitro Modules jako alternatywne podejście do tworzenia modułów natywnych. Wykorzystują one eksperymentalną interoperacyjność C++/Swift i zawierają szereg ulepszeń, które mogą poprawić wydajność w określonych scenariuszach. Podczas tej sesji omówiliśmy jednak różne kompromisy między Nitro Modules a istniejącymi TurboModules.
Choć Nitro Modules oferują korzyści wydajnościowe, mają też ograniczenia wymagające uwagi. Na przykład użycie eksperymentalnych funkcji interoperacyjności może wprowadzać złożoność lub problemy ze zgodnością nieobecne w TurboModules. Dyskusja skupiła się na tych kompromisach oraz potencjale włączenia części ulepszeń z Nitro Modules do rdzenia React Native, co umożliwiłoby programistom korzystanie z wydajniejszych modułów dostępnych dla wszystkich.
Platformy Out-of-Tree i CocoaPods
Platformy Out-of-Tree pokazują pełną moc React Native, pozwalając współdzielić jedną bazę kodu JS między różnymi platformami na urządzeniach mobilnych, komputerach czy nawet urządzeniach VR/XR. Tworzenie takich platform nie jest obecnie najprostszym procesem - brakuje wytycznych dotyczących tworzenia, rozwijania i utrzymywania. Dodatkowo rdzeń React Native jest w pewnym stopniu związany z platformami Android i iOS. W przyszłości moglibyśmy dążyć do scenariusza, gdzie wszystkie platformy są traktowane równo i integrują się z rdzeniem C++/JS poprzez te same API.
Podczas sesji opiekunowie różnych platform dyskutowali o problemach, wyzwaniach i potencjalnych rozwiązaniach mających ujednolicić proces tworzenia i utrzymywania nowych platform Out-of-Tree.
Innym aspektem sesji była dyskusja o CocoaPods i przyszłych planach zarządzania natywnymi zależnościami. Zespół CocoaPods ogłosił niedawno przejście w tryb utrzymania bez planowanych większych ulepszeń. Podczas sesji omówiliśmy zalety i wady różnych alternatyw oraz proces migracji.
React Native na komputerach stacjonarnych
Steven i Saad z Microsoftu, opiekunowie react-native-windows i react-native-macos, przeprowadzili sesję zbierającą opinie współtwórców dotyczące platform stacjonarnych. Omówiono tematy takie jak zwiększanie adopcji React Native na desktopie (np. poprzez dedykowany workflow w Visual Studio czy ekspozycję desktopa w Nx) oraz wsparcie dla Expo, które stanowi stałe wyzwanie dla szerszego przyjęcia.
Istnieje duża różnica w dostępności modułów społecznościowych między macOS a Windows, głównie dlatego, że kod iOS jest w większości zgodny z macOS, podczas gdy RNW wymaga dedykowanych implementacji. Pracując nad Nową Architekturą dla React Native for Windows, zespół dostrzega potencjał w modułach C++ umożliwiających większe współdzielenie kodu między platformami, co powinno ułatwić targetowanie platform stacjonarnych. Warto dodać, że Software Mansion pracuje nad dodaniem wsparcia desktopowego do swoich popularnych modułów, takich jak React Native Screens, Gesture Handler i Reanimated.
Nadal jesteśmy pod wrażeniem, jak kilka godzin spędzonych wspólnie przez dwa dni zaowocowało tak intensywną wymianą wiedzy i krzyżowaniem się pomysłów. Podczas tego szczytu zasialiśmy ziarna inicjatyw, które pomogą nam ulepszać i przekształcać ekosystem React Native.
Jeśli chcesz dołączyć do rozwoju React Native, dołącz do naszych otwartych inicjatyw i zapoznaj się z przewodnikiem dla współtwórców na naszej stronie. Mamy nadzieję spotkać się z Tobą osobiście w przyszłości!