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 na konferencji Chain React ogłosiliśmy Hermesa, otwartoźródłowy silnik JavaScript, nad którym pracowaliśmy w Facebooku. To mały i lekki silnik JavaScript zoptymalizowany do uruchamiania React Native na Androidzie. Sprawdź szczegóły!
Hermes poprawia wydajność React Native poprzez zmniejszenie zużycia pamięci, redukcję rozmiaru pobieranej aplikacji oraz skrócenie czasu potrzebnego na osiągnięcie stanu użyteczności aplikacji, czyli "time to interactive" (TTI).
„Analizując dane dotyczące wydajności, zauważyliśmy, że sam silnik JavaScript znacząco wpływał na czas uruchamiania i rozmiar pobieranej aplikacji. Mając te informacje, wiedzieliśmy, że musimy zoptymalizować wydajność JavaScript w bardziej ograniczonych środowiskach telefonów komórkowych w porównaniu do komputerów stacjonarnych czy laptopów. Po rozważeniu innych opcji stworzyliśmy nowy silnik JavaScript o nazwie Hermes. Został zaprojektowany, aby poprawiać wydajność aplikacji, ze szczególnym uwzględnieniem naszych aplikacji React Native, nawet na urządzeniach masowej sprzedaży o ograniczonej pamięci, wolnej pamięci masowej i mniejszej mocy obliczeniowej.” —Hermes: Otwartoźródłowy silnik JavaScript zoptymalizowany dla aplikacji mobilnych, począwszy od React Native
Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt.
Znalazłeś błąd? Zgłoś problem →
Po miesiącach ciężkiej pracy setek współtwórców, zespół React Native Core z dumą ogłasza wydanie wersji 0.60. Ta wersja obejmuje znaczące migracje zarówno dla platform Android, jak i iOS, a także rozwiązano wiele problemów. W tym wpisie na blogu przedstawiamy najważniejsze zmiane w wydaniu. Jak zawsze, szczegółowe informacje znajdziesz w dzienniku zmian. Dziękujemy wszystkim współtwórcom za pomoc w osiągnięciu tego kamienia milowego!
Ekran startowy React Native został odświeżony! Dziękujemy licznym współtwórcom, którzy pomogli stworzyć nowy interfejs. To nowe "Hello World" przywita użytkowników w ekosystemie w bardziej przyjazny i angażujący sposób.
AndroidX to duży krok naprzód w ekosystemie Androida, a stare artefakty biblioteki wsparcia są wycofywane. W wersji 0.60 React Native został zmigrowany do AndroidX. Jest to zmiana łamiąca kompatybilność wsteczną, więc twój natywny kod i zależności również będą musiały zostać zmigrowane.
Dzięki tej zmianie aplikacje React Native będą musiały zacząć używać samego AndroidX. Nie można używać ich jednocześnie w jednej aplikacji, więc cały kod aplikacji i kod zależności musi używać jednego lub drugiego.
Chociaż twój własny natywny kod będziesz musiał zmigrować samodzielnie, @mikehardy, @cawfree oraz @m4tt72 stworzyli sprytne narzędzie o nazwie "jetifier" do załatania twojego node_modules. Twórcy bibliotek będą musieli dokonać aktualizacji, ale to narzędzie zapewnia tymczasowe rozwiązanie, dając im czas na wydanie wersji dla AndroidX. Jeśli więc napotkasz błędy związane z migracją do AndroidX, wypróbuj je.
CocoaPods stały się częścią projektu iOS w React Native. Jeśli jeszcze tego nie robiłeś, od teraz pamiętaj o otwieraniu kodu platformy iOS za pomocą pliku xcworkspace (pro tip: spróbuj xed ios z głównego katalogu projektu). Dodatkowo, podspec dla pakietów wewnętrznych zostały zmienione, aby były kompatybilne z projektami Xcode, co ułatwi rozwiązywanie problemów i debugowanie. Przygotuj się na wprowadzenie prostych zmian w swoim Podfile podczas aktualizacji do wersji 0.60, aby skorzystać z tego ekscytującego udoskonalenia. Pamiętaj, że znamy problem kompatybilności z use_frameworks! i śledzimy issue z obejściami i planowaną poprawką.
WebView i NetInfo zostały wcześniej przeniesione do osobnych repozytoriów, a w wersji 0.60 zakończyliśmy ich migrację z głównego repozytorium React Native. Dodatkowo, w odpowiedzi na uwagi społeczności dotyczące nowych zasad App Store, Geolocation również został wyodrębniony. Jeśli jeszcze tego nie zrobiłeś, dokończ migrację, dodając zależności do react-native-webview, @react-native-community/netinfo oraz @react-native-community/geolocation. Jeśli wolisz zautomatyzowane rozwiązanie, rozważ użycie rn-upgrade-deprecated-modules. Opiekunowie dokonali ponad 100 commitów w tych repozytoriach od czasu wyodrębnienia – cieszymy się z takiego wsparcia społeczności!
Zespół pracujący nad React Native CLI wprowadził znaczące ulepszenia w linkowaniu modułów natywnych, nazwane autolinkingiem! W większości przypadków nie będziesz już potrzebował komendy react-native link. Jednocześnie zespół gruntownie przebudował cały proces linkowania. Pamiętaj o użyciu react-native unlink dla istniejących zależności, jak opisano w powyższej dokumentacji.
Zmiany związane z AndroidX niemal na pewno będą wymagać aktualizacji Twojej biblioteki, więc koniecznie dodaj wkrótce odpowiednie wsparcie. Jeśli nie możesz jeszcze przeprowadzić aktualizacji, rozważ przetestowanie swojej biblioteki z jetifierem, aby upewnić się, że użytkownicy będą mogli ją załatać podczas budowania.
Przejrzyj dokumentację autolinkingu, aby zaktualizować swoje konfiguracje i plik readme. W zależności od tego, jak Twoja biblioteka była wcześniej zintegrowana, możesz potrzebować dodatkowych zmian. Sprawdź przewodnik po zależnościach w CLI, aby dowiedzieć się, jak zdefiniować interfejs zależności.
Choć to tylko najważniejsze zmiany, które odnotowaliśmy, czeka nas wiele innych ekscytujących nowości. Aby zobaczyć wszystkie aktualizacje, zajrzyj do changeloga. Jak zawsze, śledźcie dalsze wieści. Tymczasem życzymy miłego korzystania z wersji 0.60!
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.
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.
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.
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.
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?”
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.
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 ✨
Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt.
Znalazłeś błąd? Zgłoś problem →
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.
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.
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:
Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt.
Znalazłeś błąd? Zgłoś problem →
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ą.
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:
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.
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.
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:
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.
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.
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!
Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt.
Znalazłeś błąd? Zgłoś problem →
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:
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.
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.
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.
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:
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.
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.
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! ⚛️✌️
Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt.
Znalazłeś błąd? Zgłoś problem →
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:
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:
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.
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.
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.
Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt.
Znalazłeś błąd? Zgłoś problem →
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ę.
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.
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.
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.
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.
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.
Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt.
Znalazłeś błąd? Zgłoś problem →
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:
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.
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).
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.
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.
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:
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ść.
Bardzo ograniczona funkcjonalność na Androidzie. Przy starej właściwości TalkBack rozpoznawał tylko elementy: "button", "radiobutton_checked" i "radiobutton_unchecked".
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.
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.
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:
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.
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.
Ten skrypt usuwa również wystąpienia AccessibilityComponentType (zakładając, że wszędzie tam, gdzie ustawiono AccessibilityComponentType, ustawiono również AccessibilityTraits).
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.
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
Ilustracja: Rachel Nabors
