55 postów z tagiem "announcement"

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.

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.

Wkrótce po wprowadzeniu React Native rozpoczęliśmy dwutygodniowy cykl wydań, aby społeczność mogła łatwiej adoptować nowe funkcje, zachowując jednocześnie stabilność wersji do użytku produkcyjnego. W Facebooku musieliśmy stabilizować kod co dwa tygodnie przed wydaniem naszych produkcyjnych aplikacji iOS, więc postanowiliśmy udostępniać wersje open source w tym samym tempie. Obecnie wiele aplikacji Facebooka publikuje aktualizacje raz w tygodniu, szczególnie na Androida. Ponieważ publikujemy z gałęzi master co tydzień, musimy utrzymywać ją w stanie stabilnym. Dlatego dwutygodniowy cykl wydań nie przynosi już korzyści nawet wewnętrznym współtwórcom.

Często otrzymujemy informacje zwrotne od społeczności, że tempo wydań jest trudne do nadążenia. Narzędzia takie jak Expo musiały pomijać co drugie wydanie, aby poradzić sobie z szybkimi zmianami wersji. Wyraźnie widać, że dwutygodniowe wydania nie służyły społeczności najlepiej.

Teraz wydajemy co miesiąc​

Z przyjemnością ogłaszamy nowy miesięczny cykl wydań oraz grudniową wersję z 2016 roku, v0.40, która była stabilizowana przez cały ostatni miesiąc i jest gotowa do adopcji. (Pamiętaj tylko o aktualizacji nagłówków w natywnych modułach na iOS).

Chociaż termin może się różnić o kilka dni, aby uniknąć weekendów lub nieprzewidzianych problemów, możesz teraz oczekiwać, że dana wersja będzie dostępna pierwszego dnia miesiąca, a oficjalnie wydana ostatniego.

Używaj bieżącego miesiąca dla najlepszego wsparcia​

Kandydat wydania styczniowego jest gotowy do testowania, a nowości możesz zobaczyć tutaj.

Aby zobaczyć nadchodzące zmiany i przekazać lepsze informacje zwrotne współtwórcom React Native, zawsze gdy to możliwe używaj kandydata wydania z bieżącego miesiąca. W momencie publikacji każdej wersji pod koniec miesiąca, zawarte w niej zmiany będą już obecne w produkcyjnych aplikacjach Facebooka od ponad dwóch tygodni.

Możesz łatwo zaktualizować swoją aplikację za pomocą nowego polecenia react-native-git-upgrade:

npm install -g react-native-git-upgrade
react-native-git-upgrade 0.41.0-rc.0

Mamy nadzieję, że to prostsze podejście ułatwi społeczności śledzenie zmian w React Native i adopcję nowych wersji tak szybko, jak to możliwe!

(Podziękowania dla Martina Koniceka za opracowanie tego planu i Mike'a Grabowskiego za jego realizację)

Aktualizacja do nowszych wersji React Native bywała trudna. Prawdopodobnie spotkałeś się już z takim komunikatem:

Żadna z tych opcji nie jest idealna. Nadpisując plik, tracimy lokalne zmiany. Nie nadpisując, nie otrzymujemy najnowszych aktualizacji.

Dziś z dumą przedstawiam nowe narzędzie rozwiązujące ten problem. Narzędzie react-native-git-upgrade wykorzystuje Git w tle, aby automatycznie rozwiązywać konflikty tam, gdzie to możliwe.

Sposób użycia​

Wymaganie: Git musi być dostępny w PATH. Twój projekt nie musi być zarządzany przez Gita.

Zainstaluj react-native-git-upgrade globalnie:

$ npm install -g react-native-git-upgrade

lub używając Yarna:

$ yarn global add react-native-git-upgrade

Następnie uruchom go w katalogu projektu:

$ cd MyProject
$ react-native-git-upgrade 0.38.0

Uwaga: Nie uruchamiaj 'npm install' aby zainstalować nową wersję react-native. Narzędzie musi móc porównać starą i nową szablon projektu. Po prostu uruchom je w folderze aplikacji jak powyżej, pozostając przy starej wersji.

Przykładowe wyjście:

Możesz też uruchomić react-native-git-upgrade bez argumentów, aby zaktualizować do najnowszej wersji React Native.

Staramy się zachować Twoje zmiany w plikach budowania Androida i iOS, więc nie musisz uruchamiać react-native link po aktualizacji.

Projektowaliśmy to rozwiązanie tak, aby było jak najmniej inwazyjne. Działa w oparciu o lokalne repozytorium Git tworzone dynamicznie w katalogu tymczasowym. Nie zakłóci działania repozytorium projektu (nieważne czy używasz Gita, SVN, Mercuriala czy niczego). Twoje źródła są przywracane w przypadku nieoczekiwanych błędów.

Jak to działa?​

Kluczowy etap to generowanie łatki Git. Ta łata zawiera wszystkie zmiany wprowadzone w szablonach React Native pomiędzy wersją używaną przez Twoją aplikację a nową wersją.

Aby uzyskać tę łatę, generujemy aplikację ze szablonów osadzonych w pakiecie react-native w Twoim katalogu node_modules (to te same szablony, których używa komenda react-native init). Po wygenerowaniu natywnych aplikacji ze szablonów dla obecnej i nowej wersji, Git może wyprodukować łatę dostosowaną do Twojego projektu (tj. zawierającą nazwę Twojej aplikacji):

[...]

diff --git a/ios/MyAwesomeApp/Info.plist b/ios/MyAwesomeApp/Info.plist
index e98ebb0..2fb6a11 100644
--- a/ios/MyAwesomeApp/Info.plist
+++ b/ios/MyAwesomeApp/Info.plist
@@ -45,7 +45,7 @@
        <dict>
            <key>localhost</key>
            <dict>
-               <key>NSTemporaryExceptionAllowsInsecureHTTPLoads</key>
+               <key>NSExceptionAllowsInsecureHTTPLoads</key>
                <true/>
            </dict>
        </dict>
[...]

Teraz wystarczy zastosować tę łatę do Twoich plików źródłowych. Podczas gdy stary proces react-native upgrade pytałby o każdą drobną różnicę, Git potrafi automatycznie scalić większość zmian używając algorytmu 3-way merge, pozostawiając ewentualnie znane znaczniki konfliktów:

    13B07F951A680F5B00A75B9A /* Release */ = {
      isa = XCBuildConfiguration;
      buildSettings = {
        ASSETCATALOG_COMPILER_APPICON_NAME = AppIcon;
<<<<<<< ours
        CODE_SIGN_IDENTITY = "iPhone Developer";
        FRAMEWORK_SEARCH_PATHS = (
          "$(inherited)",
          "$(PROJECT_DIR)/HockeySDK.embeddedframework",
          "$(PROJECT_DIR)/HockeySDK-iOS/HockeySDK.embeddedframework",
        );
=======
        CURRENT_PROJECT_VERSION = 1;
>>>>>>> theirs
        HEADER_SEARCH_PATHS = (
          "$(inherited)",
          /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include,
          "$(SRCROOT)/../node_modules/react-native/React/**",
          "$(SRCROOT)/../node_modules/react-native-code-push/ios/CodePush/**",
        );

Takie konflikty są zazwyczaj łatwe do rozstrzygnięcia. Znacznik ours oznacza "Twój zespół", natomiast theirs można rozumieć jako "zespół React Native".

Dlaczego nowy globalny pakiet?​

React Native posiada globalne CLI (pakiet react-native-cli), które deleguje polecenia do lokalnego CLI osadzonego w katalogu node_modules/react-native/local-cli.

Jak wspomnieliśmy wcześniej, proces musi zostać rozpoczęty z Twojej aktualnej wersji React Native. Gdybyśmy osadzili tę funkcjonalność w lokalnym CLI, nie moglibyście korzystać z tej funkcji przy używaniu starszych wersji React Native. Na przykład, nie bylibyście w stanie zaktualizować z wersji 0.29.2 do 0.38.0, gdyby ten nowy mechanizm aktualizacji był dostępny dopiero w wersji 0.38.0.

Aktualizacja oparta na Git to znacząca poprawa doświadczeń deweloperskich i ważne jest, aby udostępnić ją wszystkim. Dzięki użyciu oddzielnego pakietu react-native-git-upgrade zainstalowanego globalnie, możesz korzystać z tej nowej funkcji już dziś, niezależnie od wersji React Native używanego w Twoim projekcie.

Kolejnym powodem jest niedawna eliminacja Yeomana przez Martina Koniecka. Nie chcieliśmy przywracać tych zależności Yeoman do pakietu react-native tylko po to, aby móc generować łatkę poprzez porównanie starych i nowych szablonów.

Wypróbuj i przekaż swoją opinię​

Podsumowując, życzę przyjemnego korzystania z nowej funkcji i zachęcam do zgłaszania sugestii i problemów, a szczególnie przesyłania pull requestów. Każde środowisko jest nieco inne i każdy projekt React Native jest inny - Twoja opinia pomoże nam dostosować to rozwiązanie do potrzeb wszystkich użytkowników.

Podziękowania​

Serdeczne podziękowania dla wspaniałych firm Zenika i M6 Web (archived) - bez Waszego wsparcia nic z tego nie byłoby możliwe!

Wiele osób zgłaszało, że przy ogromie prac wokół React Native trudno śledzić wszystkie zmiany. Aby lepiej komunikować bieżące działania, publikujemy teraz plan rozwoju React Native. W skrócie prace skupiają się na trzech priorytetach:

• Biblioteki podstawowe. Rozszerzanie funkcjonalności kluczowych komponentów i API.

• Stabilność. Usprawnianie infrastruktury bazowej w celu redukcji błędów i poprawy jakości kodu.

• Doświadczenie deweloperskie. Przyspieszanie pracy programistów React Native.

Jeśli masz sugestie dotyczące funkcji, które Twoim zdaniem powinny znaleźć się w planie, odwiedź Canny, gdzie możesz proponować nowe funkcje i dyskutować o istniejących pomysłach.

Nowości w React Native​

Wersja 0.37 React Native, wydana dziś, wprowadza nowy podstawowy komponent ułatwiający dodawanie przycisku w każdej aplikacji. Dodajemy również obsługę nowego menedżera pakietów Yarn, który znacząco przyspiesza aktualizację zależności aplikacji.

Poznaj Button​

Dziś prezentujemy podstawowy komponent <Button />, który świetnie prezentuje się na każdej platformie. To odpowiedź na jedno z najczęstszych uwag: React Native to jedno z niewielu narzędzi do tworzenia aplikacji mobilnych bez gotowego do użycia przycisku.

<Button
  onPress={onPressMe}
  title="Press Me"
  accessibilityLabel="Learn more about this Simple Button"
/>

Doświadczeni deweloperzy React Native wiedzą, jak stworzyć przycisk: użyć TouchableOpacity dla domyślnego wyglądu na iOS, TouchableNativeFeedback dla efektu falowania na Androidzie, a następnie dodać kilka stylów. Tworzenie własnych przycisków nie jest szczególnie trudne, ale naszym celem jest maksymalne uproszczenie nauki React Native. Dzięki dodaniu podstawowego przycisku do rdzenia frameworka, nowi użytkownicy będą mogli szybko tworzyć imponujące rzeczy, zamiast tracić czas na formatowanie przycisku i poznawanie niuansów komponentów dotykowych.

Button ma działać perfekcyjnie i wyglądać natywnie na każdej platformie, więc nie obsługuje wszystkich zaawansowanych funkcji niestandardowych przycisków. To doskonały punkt startowy, ale nie zamierzamy nim zastępować wszystkich istniejących rozwiązań. Więcej informacji znajdziesz w nowej dokumentacji Button, zawierającej działający przykład!

Przyspiesz react-native init za pomocą Yarn​

Możesz teraz używać Yarn, nowego menedżera pakietów JavaScript, aby znacząco przyspieszyć react-native init. Aby skorzystać z przyspieszenia, zainstaluj yarn i zaktualizuj react-native-cli do wersji 1.2.0:

$ npm install -g react-native-cli

Podczas konfigurowania nowych aplikacji powinien pojawić się komunikat "Using yarn":

W prostych testach lokalnych react-native init kończył się w około minutę przy dobrym połączeniu (w porównaniu do ~3 minut przy użyciu npm 3.10.8). Instalacja yarn jest opcjonalna, ale zdecydowanie zalecana.

Podziękowania​

Dziękujemy wszystkim, którzy przyczynili się do tej wersji. Pełne informacje o wydaniu są dostępne na GitHubie. Dzięki ponad dwudziestu poprawkom błędów i nowym funkcjom, React Native staje się coraz lepszy dzięki Wam.