Kontynuujemy miesięczne spotkania React Native! Tym razem dołączyli do nas przedstawiciele Infinite Red, twórcy konferencji Chain React poświęconej React Native. Ponieważ większość uczestników występowała na Chain React, przełożyliśmy spotkanie o tydzień. Nagrania prelekcji zostały opublikowane online i gorąco zachęcam do ich obejrzenia. Zobaczmy, co słychać u naszych zespołów.

Zespoły​

Na drugim spotkaniu gościliśmy przedstawicieli 9 zespołów:

• Airbnb

• Callstack

• Expo

• Facebook

• GeekyAnts

• Infinite Red

• Microsoft

• Shoutem

• Wix

Notatki​

Oto podsumowania od każdego zespołu:

Airbnb​

• Zajrzyjcie do repozytorium Airbnb w poszukiwaniu projektów związanych z React Native.

Callstack​

• Mike Grabowski jak zwykle zarządza miesięcznymi wydaniami React Native, w tym kilkoma opublikowanymi wersjami beta. Szczególnie skupia się na publikacji builda v0.43.5 w npm, ponieważ to umożliwia korzystanie użytkownikom Windows!

• Prace nad Haul postępują powoli, ale systematycznie. Trwa proces dodawania HMR przez pull request, a inne ulepszenia już zostały wdrożone. Ostatnio kilku liderów branży przyjęło to rozwiązanie. Prawdopodobnie planowane jest rozpoczęcie płatnej pracy na pełen etat w tym obszarze.

• Michał Pierzchała z zespołu Jest dołączył w tym miesiącu do Callstack. Będzie pomagał w utrzymaniu Haul i prawdopodobnie pracował nad Metro Bundler oraz Jest.

• Satyajit Sahoo jest teraz z nami, hurra!

• Przygotowujemy kilka ciekawych rzeczy z naszego działu OSS. W szczególności pracujemy nad integracją Material Palette API z React Native. Planujemy wreszcie wydać nasz natywny zestaw dla iOS, który ma zapewnić wygląd i działanie identyczne jak natywnych komponentów.

Expo​

• Ostatnio uruchomiliśmy Native Directory, aby ułatwić odkrywanie i ocenę bibliotek w ekosystemie React Native. Problem: mnóstwo bibliotek, trudno je przetestować, konieczne ręczne stosowanie heurystyk i nie od razu wiadomo, które są po prostu najlepsze. Trudno też stwierdzić kompatybilność z CRNA/Expo. Native Directory próbuje rozwiązać te problemy. Sprawdź i dodaj swoją bibliotekę. Lista bibliotek jest tutaj. To dopiero nasza pierwsza wersja – chcemy, by to narzędzie należało do społeczności, nie tylko do ludzi z Expo. Pomóż, jeśli uważasz to za wartościowe!

• Dodaliśmy wstępne wsparcie instalacji pakietów npm w Snack z Expos SDK 19. Daj znać o problemach – wciąż pracujemy nad błędami. Razem z Native Directory ułatwi to testowanie bibliotek zależnych tylko od JS lub zawartych w Expo SDK. Przetestuj:

  • react-native-modal
  • react-native-animatable
  • react-native-calendars

• Wydaliśmy Expo SDK19 z licznymi ulepszeniami oraz zaktualizowanym JSC dla Androida.

• Pracujemy z Alexanderem Kotliarskyim nad poradnikiem w dokumentacji z listą wskazówek, jak poprawić UX aplikacji. Dołącz i dodaj swoje pomysły!

  • Issue: #14979
  • Initial pull request: #14993

• Kontynuujemy prace nad: audio/wideo, kamerą, gestami (ze Software Mansion, react-native-gesture-handler), integracją GL z kamerą. Planujemy wdrożenie części funkcji w SDK20 (sierpień) oraz znaczące ulepszenia innych. Rozpoczynamy też budowę infrastruktury w kliencie Expo do pracy w tle (geolokalizacja, audio, powiadomienia itp.).

• Adam Miskiewicz poczynił postępy w imitacji przejść z UINavigationController w react-navigation. Zobacz wczesną wersję w jego tweecie – wkrótce premiera. Sprawdź też MaskedViewIOS, który włączył do głównego kodu. Jeśli masz umiejętności, zaimplementuj MaskedView dla Androida – byłoby świetnie!

Facebook​

• Facebook wewnętrznie eksperymentuje z osadzaniem natywnych komponentów ComponentKit i Litho wewnątrz React Native.

• Wkład w React Native jest bardzo mile widziany! Jeśli zastanawiasz się, jak możesz się przyczynić, poradnik "Jak wnosić swój wkład" opisuje nasz proces rozwojowy i przedstawia kroki do wysłania swojego pierwszego pull requesta. Istnieją również inne sposoby wniesienia wkładu, które nie wymagają pisania kodu, jak np. triaż zgłoszeń (issues) lub aktualizacja dokumentacji.

  • W chwili pisania React Native ma 635 otwartych zgłoszeń i 249 otwartych pull requestów. To przytłacza naszych maintainerów, a gdy problemy są naprawiane wewnętrznie, trudno jest upewnić się, że odpowiednie zadania są aktualizowane.
  • Nie jesteśmy pewni, jakie podejście byłoby najlepsze, aby to ogarnąć przy jednoczesnym zadowoleniu społeczności. Niektóre (ale nie wszystkie!) opcje obejmują zamykanie nieaktualnych zgłoszeń, nadanie znacznie większej liczbie osób uprawnień do zarządzania zgłoszeniami oraz automatyczne zamykanie zgłoszeń niespełniających szablonu. Napisaliśmy przewodnik "Czego oczekiwać od maintainerów", aby ustalić oczekiwania i uniknąć niespodzianek. Jeśli masz pomysły, jak możemy ulepszyć to doświadczenie dla maintainerów, jednocześnie zapewniając, że osoby zgłaszające problemy i pull requesty czują się wysłuchane i docenione – daj nam znać!

GeekyAnts​

• Zaprezentowaliśmy Designer Tool współpracujący z plikami React Native na Chain React. Wielu uczestników zapisało się na listę oczekujących.

• Przyglądamy się również innym rozwiązaniom cross-platformowym jak Google Flutter (nadchodzi poważne porównanie), Kotlin Native i Apache Weex, aby zrozumieć różnice architektoniczne i co możemy się od nich nauczyć, by poprawić ogólną wydajność React Native.

• Przeszliśmy na react-navigation w większości naszych aplikacji, co poprawiło ogólną wydajność.

• Ogłosiliśmy również NativeBase Market – platformę z komponentami i aplikacjami React Native (dla developerów i przez developerów).

Infinite Red​

• Chcemy przedstawić Reactotron. Zobacz film wprowadzający. Wkrótce dodamy więcej funkcji!

• Zorganizowaliśmy konferencję Chain React. Była świetna, dziękujemy wszystkim za przybycie! Nagrania są już dostępne online!

Microsoft​

• CodePush został zintegrowany z Mobile Center. Obecni użytkownicy nie zauważą zmian w swoim workflow.

  • Niektórzy zgłaszali problem z duplikowaniem aplikacji – mieli już aplikację w Mobile Center. Pracujemy nad rozwiązaniem, ale jeśli masz dwie aplikacje, daj nam znać, a połączymy je dla Ciebie.

• Mobile Center obsługuje teraz powiadomienia push (Push Notifications) dla CodePush. Pokazaliśmy też, jak kombinacja Powiadomień i CodePush może być użyta do testów A/B aplikacji – coś unikalnego dla architektury ReactNative.

• VS Code ma znany problem z debugowaniem ReactNative – następna wersja rozszerzenia, która ukaże się za kilka dni, naprawi ten błąd.

• Ponieważ wiele innych zespołów w Microsoft również pracuje nad React Native, postaramy się o lepszą reprezentację wszystkich grup na następnym spotkaniu.

Shoutem​

• Zakończyliśmy proces upraszczania rozwoju React Native na Shoutem. Możesz używać wszystkich standardowych komend react-native podczas tworzenia aplikacji na Shoutem.

• Włożyliśmy dużo pracy w ustalenie najlepszego podejścia do profilowania w React Native. Duża część dokumentacji jest nieaktualna, więc postaramy się przygotować pull request do oficjalnej dokumentacji lub przynajmniej opisać nasze wnioski w poście na blogu.

• Przestawiamy nasze rozwiązanie nawigacyjne na react-navigation, więc wkrótce możemy podzielić się uwagami.

• Wydaliśmy nowy komponent HTML w naszym zestawie narzędzi, który przekształca surowy HTML w drzewo komponentów React Native.

Wix​

• Rozpoczęliśmy pracę nad pull requestem do Metro Bundler z funkcjami react-native-repackager. Zaktualizowaliśmy react-native-repackager do obsługi RN 44 (którego używamy w produkcji). Wykorzystujemy go w naszej infrastrukturze mockującej dla detox.

• Przez ostatnie trzy tygodnie pokrywaliśmy aplikację Wix testami detox. To niesamowite doświadczenie pokazujące, jak redukować manualne QA w aplikacji tej skali (ponad 40 inżynierów). Naprawiliśmy kilka problemów z detoxem - właśnie opublikowaliśmy nową wersję. Z przyjemnością donoszę, że spełniamy założenia "polityki zerowej flakiness" i testy konsekwentnie przechodzą.

• Detox dla Androida posuwa się naprzód. Otrzymujemy znaczącą pomoc od społeczności. Spodziewamy się wstępnej wersji za około dwa tygodnie.

• DetoxInstruments, nasze narzędzie do testowania wydajności, rozrosło się bardziej niż pierwotnie planowaliśmy. Planujemy przekształcić je w samodzielne narzędzie niepowiązane ściśle z detoxem. Pozwoli ono analizować wydajność aplikacji iOS w ogóle. Będzie też zintegrowane z detoxem, co umożliwi automatyzację testów metryk wydajności.

Kolejne spotkanie​

Następne spotkanie odbędzie się 16 sierpnia 2017 roku. Ponieważ to dopiero nasze drugie spotkanie, chcielibyśmy wiedzieć, czy te notatki przynoszą korzyść społeczności React Native. Zachęcamy do kontaktu na Twitterze z sugestiami, jak możemy ulepszyć rezultaty tych spotkań.

W Shoutem mieliśmy to szczęście, że pracujemy z React Native od samego początku. Od pierwszego dnia chcieliśmy być częścią tej niesamowitej społeczności. Dość szybko zrozumieliśmy, że niemal niemożliwe jest nadążenie za tempem jej rozwoju i ulepszeń. Dlatego postanowiliśmy zorganizować comiesięczne spotkania, na których główni współtwórcy React Native mogą krótko przedstawić swoje działania i plany.

Comiesięczne spotkania​

Pierwszą sesję spotkań odbyliśmy 14 czerwca 2017. Misja miesięcznika React Native jest prosta i jasna: ulepszać społeczność React Native. Prezentowanie działań zespołów ułatwia współpracę między nimi poza spotkaniami.

Zespoły​

Na pierwszym spotkaniu gościliśmy 8 zespołów:

• Airbnb

• Callstack

• Expo

• Facebook

• GeekyAnts

• Microsoft

• Shoutem

• Wix

Mamy nadzieję, że w kolejnych sesjach dołączą kolejni kluczowi współtwórcy!

Notatki​

Ponieważ plany zespołów mogą zainteresować szersze grono, będziemy je udostępniać tutaj, na blogu React Native. Oto one:

Airbnb​

• Planują dodać API dostępności (A11y) do komponentu View i natywnego modułu AccessibilityInfo.

• Będą badać możliwość dodania API do modułów natywnych na Androida, pozwalających na określanie wątków, na których mają działać.

• Badają potencjalne usprawnienia wydajności inicjalizacji.

• Pracują nad bardziej zaawansowanymi strategiami pakowania, opartymi na rozwiązaniu "unbundle".

Callstack​

• Pracują nad ulepszeniem procesu wydań poprzez wykorzystanie Detox do testów E2E. Pull request powinien wkrótce zostać zaakceptowany.

• Ich pull request dotyczący Blob został już scalony, kolejne są w przygotowaniu.

• Zwiększają wykorzystanie Haul w projektach wewnętrznych, aby porównać jego działanie z Metro Bundler. Współpracują z zespołem webpack nad lepszą wydajnością wielowątkową.

• Wewnętrznie wdrożyli lepszą infrastrukturę do zarządzania projektami open source. Planują publikować więcej w nadchodzących tygodniach.

• Konferencja React Native Europe jest w przygotowaniu - na razie nic szczególnego, ale wszyscy jesteście zaproszeni!

• Tymczasowo wycofali się z pracy nad react-navigation, aby zbadać alternatywy (szczególnie natywne rozwiązania nawigacyjne).

Expo​

• Pracują nad umożliwieniem instalacji modułów npm w Snack, co ułatwi bibliotekom dodawanie przykładów do dokumentacji.

• Współpraca z Krzysztofem i innymi osobami w Software Mansion nad aktualizacją JSC na Androida oraz biblioteką do obsługi gestów.

• Adam Miskiewicz koncentruje się teraz na react-navigation.

• Create React Native App zostało dodane do przewodnika dla początkujących w dokumentacji. Expo zachęca autorów bibliotek do jasnego określania, czy ich biblioteka współpracuje z CRNA, a jeśli tak – do wyjaśnienia konfiguracji.

Facebook​

• Pakowarka React Native stała się niezależnym projektem o nazwie Metro Bundler. Zespół Metro w Londynie chce lepiej odpowiadać na potrzeby społeczności, poprawić modularność dla przypadków użycia wykraczających poza React Native oraz zwiększyć responsywność w kwestiach problemów i pull requestów.

• W nadchodzących miesiącach zespół React Native skupi się na udoskonalaniu API komponentów prymitywnych. Oczekujcie poprawy w zakresie niuansów układu, dostępności i typowania flow.

• Zespół planuje także w tym roku poprawić modularność rdzenia poprzez refaktoryzację umożliwiającą pełne wsparcie platform stron trzecich, takich jak Windows i macOS.

GeekyAnts​

• Zespół pracuje nad aplikacją do projektowania UI/UX (kryptonim: Builder), która bezpośrednio współpracuje z plikami .js. Obecnie obsługuje tylko React Native. Działa podobnie jak Adobe XD i Sketch.

• Pracują nad możliwością wczytania istniejącej aplikacji React Native w edytorze, wprowadzania zmian (wizualnie, jak projektant) i zapisywania zmian bezpośrednio w pliku JS.

• Chcą zasypać przepaść między projektantami a developerami i połączyć ich w ramach jednego repozytorium.

• Ponadto NativeBase niedawno osiągnął 5000 gwiazdek na GitHubie.

Microsoft​

• CodePush został zintegrowany z Mobile Center. To pierwszy krok w zapewnianiu lepiej zintegrowanego doświadczenia z dystrybucją, analityką i innymi usługami. Ogłoszenie dostępne jest tutaj.

• W VS Code występuje błąd związany z debugowaniem – obecnie nad nim pracują i wkrótce udostępnią nowy build.

• Badają możliwość użycia Detox do testów integracyjnych, analizują kontekst JSC w celu pozyskiwania zmiennych wraz z raportami awarii.

Shoutem​

• Usprawnianie pracy z aplikacjami Shoutem przy użyciu narzędzi społeczności React Native. Użytkownicy będą mogli korzystać ze wszystkich poleceń React Native do uruchamiania aplikacji tworzonych w Shoutem.

• Badanie narzędzi profilujących dla React Native. Mieli wiele problemów z konfiguracją i podzielą się odkrytymi wnioskami.

• Shoutem pracuje nad ułatwieniem integracji React Native z istniejącymi natywnymi aplikacjami. Udokumentują opracowany wewnętrznie koncept, aby uzyskać informacje zwrotne od społeczności.

Wix​

• Prace wewnętrzne nad wdrożeniem Detox w celu przeniesienia znaczących części aplikacji Wix na model "zero manualnej kontroli jakości". W efekcie Detox jest intensywnie używany w środowisku produkcyjnym przez dziesiątki developerów i szybko dojrzewa.

• Prace nad dodaniem wsparcia w Metro Bundler dla nadpisywania dowolnych rozszerzeń plików podczas budowania. Zamiast tylko "ios" i "android", obsługiwane będą dowolne rozszerzenia jak "e2e" czy "detox". Planowane wykorzystanie do mockowania testów E2E. Istnieje już biblioteka react-native-repackager, obecnie trwają prace nad pull requestem.

• Badanie możliwości automatyzacji testów wydajnościowych. Nowe repozytorium o nazwie DetoxInstruments. Możecie zajrzeć - rozwój odbywa się otwarcie.

• Współpraca z kontrybutorem z KPN nad Detox dla Androida i obsługą rzeczywistych urządzeń.

• Rozważanie koncepcji "Detox jako platformy" umożliwiającej budowanie innych narzędzi wymagających automatyzacji symulatora/urządzenia. Przykładem może być Storybook dla React Native lub pomysł Rama na testy integracyjne.

Kolejne spotkanie​

Spotkania odbywać się będą co cztery tygodnie. Następna sesja zaplanowana jest na 12 lipca 2017. Ponieważ dopiero zaczynamy tę inicjatywę, chcielibyśmy wiedzieć, jak te notatki służą społeczności React Native. Zapraszam do kontaktu na Twitterze jeśli macie sugestie, co powinniśmy poruszyć na kolejnych spotkaniach lub jak usprawnić ich rezultaty.

Wielu z Was już eksperymentowało z naszymi nowymi komponentami list po zapowiedzi w grupie społeczności, ale dziś oficjalnie je ogłaszamy! Koniec z ListView czy DataSource, nieaktualnymi wierszami, ignorowanymi błędami i nadmiernym zużyciem pamięci - z najnowszym kandydatem wydania React Native z marca 2017 (0.43-rc.1) możecie wybrać z nowej gamy komponentów najlepiej pasujący do Waszych potrzeb, z doskonałą wydajnością i bogatymi funkcjami od razu po wdrożeniu:

<FlatList>​

To podstawowy komponent do tworzenia prostych, wydajnych list. Podaj tablicę danych i funkcję renderItem - to wszystko, czego potrzebujesz:

<FlatList
  data={[{title: 'Title Text', key: 'item1'}, ...]}
  renderItem={({item}) => <ListItem title={item.title} />}
/>

<SectionList>​

Jeśli chcesz wyświetlić dane podzielone na logiczne sekcje, być może z nagłówkami (np. w książce adresowej ułożonej alfabetycznie), a także obsłużyć różnorodne dane i renderowanie (np. widok profilu z przyciskami, edytorem treści, siatką zdjęć, siatką znajomych i listą historii), to właściwy wybór.

<SectionList
  renderItem={({item}) => <ListItem title={item.title} />}
  renderSectionHeader={({section}) => <H1 title={section.key} />}
  sections={[ // homogeneous rendering between sections
    {data: [...], key: ...},
    {data: [...], key: ...},
    {data: [...], key: ...},
  ]}
/>

<SectionList
  sections={[ // heterogeneous rendering between sections
    {data: [...], key: ..., renderItem: ...},
    {data: [...], key: ..., renderItem: ...},
    {data: [...], key: ..., renderItem: ...},
  ]}
/>

<VirtualizedList>​

Implementacja niskopoziomowa z bardziej elastycznym API. Szczególnie przydatna, gdy dane nie są w zwykłej tablicy (np. niemutowalna lista).

Funkcje​

Listy są używane w wielu kontekstach, więc wyposażyliśmy nowe komponenty w funkcje pokrywające większość przypadków użycia:

• Ładowanie przy przewijaniu (onEndReached).

• Odświeżanie przez przeciągnięcie (onRefresh / refreshing).

• Konfigurowalne callbacki widoczności (VPV) (onViewableItemsChanged / viewabilityConfig).

• Tryb poziomy (horizontal).

• Inteligentne separatory elementów i sekcji.

• Obsługa wielu kolumn (numColumns)

• scrollToEnd, scrollToIndex i scrollToItem

• Lepsze typowanie Flow.

Ważne uwagi​

• Stan wewnętrzny poddrzew elementów nie jest zachowywany po opuszczeniu obszaru renderowania. Upewnij się, że wszystkie dane są przechowywane w danych elementów lub zewnętrznych magazynach jak Flux, Redux czy Relay.

• Te komponenty bazują na PureComponent, co oznacza że nie będą ponownie renderowane jeśli props pozostaną płytko-równe. Upewnij się, że wszystkie elementy od których zależy funkcja renderItem są przekazywane jako prop, który nie jest === po aktualizacji, inaczej interfejs może nie odświeżać zmian. Dotyczy to propa data i stanu komponentu nadrzędnego. Przykład:

  <FlatList
    data={this.state.data}
    renderItem={({item}) => (
      <MyItem
        item={item}
        onPress={() =>
          this.setState(oldState => ({
            selected: {
              // New instance breaks `===`
              ...oldState.selected, // copy old data
              [item.key]: !oldState.selected[item.key], // toggle
            },
          }))
        }
        selected={
          !!this.state.selected[item.key] // renderItem depends on state
        }
      />
    )}
    selected={
      // Can be any prop that doesn't collide with existing props
      this.state.selected // A change to selected should re-render FlatList
    }
  />
  

• Dla oszczędności pamięci i płynności przewijania, treść renderowana jest asynchronicznie poza ekranem. Może to powodować chwilowe puste miejsca przy szybkim przewijaniu. To kompromis dostosowywany do potrzeb aplikacji, nad którym aktywnie pracujemy.

• Domyślnie nowe listy szukają propa key na każdym elemencie i używają go jako klucza Reacta. Alternatywnie możesz podać własną funkcję keyExtractor.

Wydajność​

Oprócz uproszczenia API, nowe komponenty list oferują znaczną poprawę wydajności. Kluczową zaletą jest niemal stałe zużycie pamięci niezależnie od liczby wierszy. Osiąga się to poprzez "wirtualizację" elementów znajdujących się poza obszarem renderowania - są one całkowicie odmontowywane z hierarchii komponentów, co pozwala odzyskać pamięć JavaScript po komponentach Reacta oraz pamięć natywną z drzewa cieni i widoków UI. Ma to jednak konsekwencję: wewnętrzny stan komponentów nie jest zachowywany, dlatego wszelkie ważne stany muszą być przechowywane poza komponentami, np. w sklepie Relay, Redux lub Flux.

Ograniczenie obszaru renderowania zmniejsza również obciążenie Reacta i platformy natywnej (np. związane z przechodzeniem widoków). Nawet podczas renderowania milionowego elementu, nowe listy nie wymagają iteracji przez wszystkie poprzednie elementy. Możesz nawet przeskoczyć do środka listy za pomocą scrollToIndex bez nadmiernego renderowania.

Wprowadziliśmy też ulepszenia w planowaniu zadań, które poprawiają responsywność aplikacji. Elementy na granicy obszaru renderowania są przetwarzane rzadziej i z niższym priorytetem, po zakończeniu aktywnych gestów, animacji lub innych interakcji.

Zaawansowane zastosowania​

W przeciwieństwie do ListView, wszystkie elementy w obszarze renderowania są ponownie renderowane przy każdej zmianie właściwości (props). Zwykle nie stanowi to problemu dzięki ograniczonej liczbie widocznych elementów, ale przy skomplikowanych strukturach warto stosować najlepsze praktyki wydajnościowe Reacta: używaj React.PureComponent i/lub shouldComponentUpdate w swoich komponentach, aby ograniczyć ponowne renderowanie poddrzew.

Jeśli możesz obliczyć wysokość wierszy bez ich renderowania, podaj właściwość getItemLayout dla lepszego doświadczenia użytkownika. Umożliwi to płynniejsze przewijanie do konkretnych pozycji (np. za pomocą scrollToIndex) oraz poprawi wygląd wskaźnika przewijania, ponieważ wysokość zawartości będzie znana bez renderowania.

Do alternatywnych typów danych (np. niemutowalnych list) najlepiej użyć <VirtualizedList>. Akceptuje on właściwość getItem zwracającą dane elementu dla dowolnego indeksu i ma bardziej elastyczne typowanie Flow.

W nietypowych przypadkach możesz dostosować różne parametry: windowSize (kompromis między pamięcią a UX), maxToRenderPerBatch (dostosowanie szybkości wypełniania), onEndReachedThreshold (kontrola ładowania przy przewijaniu) i inne.

Planowane prace​

• Migracja istniejących komponentów (ostateczne wycofanie ListView)

• Dodawanie nowych funkcji w odpowiedzi na potrzeby (dajcie nam znać!)

• Obsługa przyklejających się nagłówków sekcji

• Dodatkowe optymalizacje wydajności

• Wsparcie dla funkcyjnych komponentów elementów ze stanem

W Facebooku często potrzebujemy uzyskiwać dostępu do głęboko zagnieżdżonych wartości w strukturach danych pobieranych za pomocą GraphQL. Podczas uzyskiwania dostępu do tych głęboko zagnieżdżonych wartości, typowe jest występowanie jednego lub więcej pól pośrednich, które mogą przyjmować wartość null. Te pola pośrednie mogą być nullem z różnych powodów - od nieudanych kontroli prywatności po sam fakt, że null okazuje się najbardziej elastycznym sposobem reprezentowania błędów niefatalnych.

Niestety, uzyskiwanie dostępu do tych głęboko zagnieżdżonych wartości jest obecnie żmudne i rozwlekłe.

props.user &&
  props.user.friends &&
  props.user.friends[0] &&
  props.user.friends[0].friends;

Istnieje propozycja w ECMAScript wprowadzenia operatora egzystencjalnego, co znacznie uprościłoby tę operację. Ale do czasu finalizacji tej propozycji, potrzebowaliśmy rozwiązania, które poprawi jakość naszego kodu, zachowa istniejącą semantykę języka i wspiera bezpieczeństwo typów dzięki Flow.

Stworzyliśmy w tym celu funkcję egzystencjalną, którą nazwaliśmy idx.

idx(props, _ => _.user.friends[0].friends);

Wywołanie w tym fragmencie kodu zachowuje się podobnie do wyrażenia logicznego w powyższym przykładzie, ale z znacznie mniejszą ilością powtórzeń. Funkcja idx przyjmuje dokładnie dwa argumenty:

• Dowolną wartość, zazwyczaj obiekt lub tablicę, w której chcesz uzyskać dostęp do zagnieżdżonej wartości.

• Funkcję, która otrzymuje pierwszy argument i uzyskuje dostęp do zagnieżdżonej wartości na nim.

Teoretycznie, funkcja idx będzie przechwytywać błędy wynikające z odwoływania się do właściwości na null lub undefined. Jeśli taki błąd zostanie przechwycony, zwróci null lub undefined. (Możesz zobaczyć, jak można to zaimplementować w idx.js.)

W praktyce przechwytywanie każdego zagnieżdżonego dostępu do właściwości jest wolne, a rozróżnianie konkretnych rodzajów błędów TypeError jest niestabilne. Aby rozwiązać te problemy, stworzyliśmy wtyczkę Babel, która przekształca powyższe wywołanie idx w następujące wyrażenie:

props.user == null
  ? props.user
  : props.user.friends == null
    ? props.user.friends
    : props.user.friends[0] == null
      ? props.user.friends[0]
      : props.user.friends[0].friends;

Na końcu dodaliśmy niestandardową deklarację typu Flow dla idx, która pozwala na prawidłowe sprawdzanie typów podczas przechodzenia w drugim argumencie, jednocześnie umożliwiając zagnieżdżony dostęp do właściwości mogących przyjmować wartość null.

Funkcja, wtyczka Babel i deklaracja Flow są teraz dostępne na GitHubie. Można ich używać instalując pakiety npm idx i babel-plugin-idx, a następnie dodając "idx" do listy wtyczek w pliku .babelrc.

Dziś prezentujemy Create React Native App: nowe narzędzie, które znacząco ułatwia rozpoczęcie pracy z projektem React Native! Jest ono mocno inspirowane projektem Create React App i powstało we współpracy między Facebookiem a Expo (dawniej Exponent).

Wielu programistów boryka się z instalacją i konfiguracją natywnych zależności budowania w React Native, szczególnie na Androida. Dzięki Create React Native App nie ma potrzeby używania Xcode czy Android Studio, a możesz tworzyć aplikacje na iOS nawet pracując na Linuxie lub Windowsie. Jest to możliwe dzięki aplikacji Expo, która ładuje i uruchamia projekty CRNA napisane w czystym JavaScript bez kompilacji kodu natywnego.

Wypróbuj utworzenie nowego projektu (zastąp odpowiednimi komendami yarn jeśli go używasz):

$ npm i -g create-react-native-app
$ create-react-native-app my-project
$ cd my-project
$ npm start

Spowoduje to uruchomienie pakowacza React Native i wygenerowanie kodu QR. Otwórz go w aplikacji Expo aby załadować swój JavaScript. Wywołania console.log są przekazywane do twojego terminala. Możesz korzystać ze standardowych API React Native oraz z Expo SDK.

A co z kodem natywnym?​

Wiele projektów React Native ma zależności w Javie lub Objective-C/Swift wymagające kompilacji. Aplikacja Expo zawiera API do obsługi kamery, wideo, kontaktów i innych, a także dołącza popularne biblioteki jak react-native-maps od Airbnb czy uwierzytelnianie Facebooka. Jeśli jednak potrzebujesz natywnej zależności, której Expo nie dołącza, prawdopodobnie będziesz musiał skonfigurować własny proces budowania. Podobnie jak w Create React App, CRNA obsługuje proces "wysunięcia" (ejecting).

Możesz uruchomić npm run eject aby uzyskać projekt bardzo podobny do tego generowanego przez react-native init. Od tego momentu będziesz potrzebować Xcode i/lub Android Studio, tak jak przy użyciu react-native init, dodawanie bibliotek za pomocą react-native link będzie działać, a ty zyskasz pełną kontrolę nad procesem kompilacji kodu natywnego.

Pytania? Opinie?​

Create React Native App jest już wystarczająco stabilne do powszechnego użytku, co oznacza że nie możemy się doczekać waszych opinii! Możesz znaleźć mnie na Twitterze lub zgłosić problem w repozytorium GitHub. Pull requesty są bardzo mile widziane!

Przez ostatni rok pracowaliśmy nad poprawą wydajności animacji wykorzystujących bibliotekę Animated. Animacje są kluczowe dla stworzenia pięknego doświadczenia użytkownika, ale mogą być trudne do poprawnego zaimplementowania. Chcemy ułatwić developerom tworzenie wydajnych animacji bez obaw, że fragmenty ich kodu spowodują opóźnienia.

Co to jest?​

API Animated zostało zaprojektowane z ważnym ograniczeniem: jest serializowalne. Oznacza to, że możemy przesłać wszystkie informacje o animacji do warstwy natywnej jeszcze przed jej rozpoczęciem, co pozwala natywnemu kodowi wykonywać animację na wątku UI bez konieczności przechodzenia przez mostek w każdej klatce. To niezwykle przydatne, ponieważ po rozpoczęciu animacji wątek JS może zostać zablokowany, a animacja nadal będzie płynnie działać. W praktyce zdarza się to często, ponieważ kod użytkownika działa na wątku JS, a renderowania Reacta również mogą blokować JS na długi czas.

Trochę historii...​

Projekt rozpoczął się około roku temu, gdy Expo zbudowało aplikację li.st na Androida. Krzysztof Magiera został zatrudniony do stworzenia początkowej implementacji na Androida. Zakończyło się to sukcesem i li.st była pierwszą aplikacją korzystającą z animacji sterowanych natywnie za pomocą Animated. Kilka miesięcy później Brandon Withrow zbudował początkową implementację na iOS. Następnie Ryan Gomba i ja pracowaliśmy nad dodaniem brakujących funkcji, takich jak obsługa Animated.event, oraz naprawą błędów wykrytych podczas używania tej technologii w aplikacjach produkcyjnych. To był prawdziwie wspólnotowy wysiłek i chciałbym podziękować wszystkim zaangażowanym oraz Expo za sponsorowanie znacznej części rozwoju. Obecnie technologia jest używana przez komponenty Touchable w React Native oraz animacje nawigacyjne w nowo wydanej bibliotece React Navigation.

Jak to działa?​

Najpierw przyjrzyjmy się, jak obecnie działają animacje z użyciem Animated ze sterownikiem JS. Podczas korzystania z Animated deklarujesz graf węzłów reprezentujących animacje, które chcesz wykonać, a następnie używasz sterownika do aktualizacji wartości Animated za pomocą predefiniowanej krzywej. Możesz również aktualizować wartość Animated, łącząc ją ze zdarzeniem View przy użyciu Animated.event.

Oto podział kroków animacji i miejsc ich wykonywania:

• JS: Sterownik animacji używa requestAnimationFrame do wykonywania w każdej klatce i aktualizuje sterowaną wartość przy użyciu nowej wartości obliczonej na podstawie krzywej animacji.

• JS: Obliczane są wartości pośrednie i przekazywane do węzła właściwości dołączonego do View.

• JS: View jest aktualizowany za pomocą setNativeProps.

• Mostek JS do Native.

• Natywny: Aktualizowany jest UIView lub android.View.

Jak widać, większość pracy odbywa się na wątku JS. Jeśli zostanie on zablokowany, animacja będzie pomijać klatki. Dodatkowo w każdej klatce musi przechodzić przez mostek JS-Native, aby aktualizować widoki natywne.

Sterownik natywny przenosi wszystkie te kroki do warstwy natywnej. Ponieważ Animated generuje graf animowanych węzłów, może być on zserializowany i wysłany do natywnego kodu tylko raz przy rozpoczęciu animacji, eliminując potrzebę wywołań zwrotnych do wątku JS. Kod natywny może samodzielnie aktualizować widoki bezpośrednio na wątku UI w każdej klatce.

Oto przykład, jak możemy serializować wartość animowaną i węzeł interpolacji (nie jest to dokładna implementacja, tylko przykład).

Utwórz natywny węzeł wartości - to wartość, która będzie animowana:

NativeAnimatedModule.createNode({
  id: 1,
  type: 'value',
  initialValue: 0,
});

Utwórz natywny węzeł interpolacji – informuje sterownik natywny, jak interpolować wartość:

NativeAnimatedModule.createNode({
  id: 2,
  type: 'interpolation',
  inputRange: [0, 10],
  outputRange: [10, 0],
  extrapolate: 'clamp',
});

Utwórz natywny węzeł właściwości – informuje sterownik natywny, do której właściwości widoku jest podpięty:

NativeAnimatedModule.createNode({
  id: 3,
  type: 'props',
  properties: ['style.opacity'],
});

Połącz węzły ze sobą:

NativeAnimatedModule.connectNodes(1, 2);
NativeAnimatedModule.connectNodes(2, 3);

Podłącz węzeł właściwości do widoku:

NativeAnimatedModule.connectToView(3, ReactNative.findNodeHandle(viewRef));

Dzięki temu natywny moduł animacji ma wszystkie informacje potrzebne do bezpośredniej aktualizacji widoków natywnych bez konieczności odwoływania się do JS w celu obliczenia wartości.

Pozostaje tylko uruchomić animację, określając typ krzywej animacyjnej i wartość animowaną do aktualizacji. Animacje czasowe można uprościć, obliczając wcześniej w JS każdą klatkę animacji, aby zmniejszyć implementację natywną.

NativeAnimatedModule.startAnimation({
  type: 'timing',
  frames: [0, 0.1, 0.2, 0.4, 0.65, ...],
  animatedValueId: 1,
});

A oto szczegółowy opis działania animacji:

• Natywny: Sterownik animacji natywnej używa CADisplayLink lub android.view.Choreographer, aby wykonywać się przy każdej klatce i aktualizować sterowaną wartość przy użyciu nowej wartości obliczonej na podstawie krzywej animacji.

• Natywny: Obliczane są wartości pośrednie i przekazywane do węzła właściwości podpiętego do widoku natywnego.

• Natywny: Aktualizowany jest UIView lub android.View.

Jak widać, brak wątku JS i brak mostu – to oznacza szybsze animacje! 🎉🎉

Jak użyć tego w mojej aplikacji?​

W przypadku standardowych animacji odpowiedź jest prosta: wystarczy dodać useNativeDriver: true do konfiguracji animacji przy jej uruchamianiu.

Przed:

Animated.timing(this.state.animatedValue, {
  toValue: 1,
  duration: 500,
}).start();

Po:

Animated.timing(this.state.animatedValue, {
  toValue: 1,
  duration: 500,
  useNativeDriver: true, // <-- Add this
}).start();

Wartości animowane są kompatybilne tylko z jednym sterownikiem, więc jeśli używasz sterownika natywnego przy uruchamianiu animacji na wartości, upewnij się że każda animacja tej wartości również go używa.

Działa to również z Animated.event, co jest szczególnie przydatne przy animacjach śledzących pozycję przewijania – bez sterownika natywnego zawsze działałyby z opóźnieniem jednej klatki względem gestu z powodu asynchronicznej natury React Native.

Przed:

<ScrollView
  scrollEventThrottle={16}
  onScroll={Animated.event(
    [{ nativeEvent: { contentOffset: { y: this.state.animatedValue } } }]
  )}
>
  {content}
</ScrollView>

Po:

<Animated.ScrollView // <-- Use the Animated ScrollView wrapper
  scrollEventThrottle={1} // <-- Use 1 here to make sure no events are ever missed
  onScroll={Animated.event(
    [{ nativeEvent: { contentOffset: { y: this.state.animatedValue } } }],
    { useNativeDriver: true } // <-- Add this
  )}
>
  {content}
</Animated.ScrollView>

Ograniczenia​

Nie wszystkie funkcje Animated są obecnie obsługiwane w Native Animated. Główne ograniczenie: można animować tylko właściwości niezwiązane z układem – działają np. transform i opacity, ale właściwości Flexbox i position już nie. Kolejne: Animated.event działa tylko z bezpośrednimi zdarzeniami, nie z propagującymi. Oznacza to, że nie współpracuje z PanResponder, ale działa np. z ScrollView#onScroll.

Native Animated jest częścią React Native od dłuższego czasu, ale nie był dokumentowany, ponieważ uznawano go za eksperymentalny. Upewnij się więc, że używasz aktualnej wersji React Native (0.40+), jeśli chcesz z tej funkcji korzystać.

Zasoby​

Więcej informacji o animacjach: polecam ten wykład Christophera Chedeau.

Jeśli chcesz dogłębnie zrozumieć animacje i jak przenoszenie ich do natywnego kodu poprawia UX, obejrzyj też ten wykład Krzysztofa Magiery.

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.

Dziś wydajemy React Native 0.36. Czytaj dalej, aby dowiedzieć się więcej o nowościach.

Headless JS​

Headless JS to sposób na uruchamianie zadań w JavaScript, gdy aplikacja działa w tle. Może być używany np. do synchronizacji świeżych danych, obsługi powiadomień push lub odtwarzania muzyki. Na razie dostępny jest tylko na Androida.

Aby rozpocząć, zdefiniuj swoje zadanie asynchroniczne w dedykowanym pliku (np. SomeTaskName.js):

module.exports = async taskData => {
  // Perform your task here.
};

Następnie zarejestruj zadanie w AppRegistry:

AppRegistry.registerHeadlessTask('SomeTaskName', () =>
  require('SomeTaskName'),
);

Użycie Headless JS wymaga napisania natywnego kodu Java, aby umożliwić uruchomienie usługi w razie potrzeby. Zajrzyj do naszej nowej dokumentacji Headless JS, aby dowiedzieć się więcej!

API klawiatury​

Praca z klawiaturą ekranową jest teraz łatwiejsza dzięki Keyboard. Możesz teraz nasłuchiwać natywnych zdarzeń klawiatury i na nie reagować. Na przykład, aby zamknąć aktywną klawiaturę, wystarczy wywołać Keyboard.dismiss():

import {Keyboard} from 'react-native';

// Hide that keyboard!
Keyboard.dismiss();

Dzielenie animowanych wartości​

Łączenie dwóch animowanych wartości przez dodawanie, mnożenie i modulo było już obsługiwane w React Native. W wersji 0.36 dodano możliwość dzielenia animowanych wartości. Są przypadki, gdy animowana wartość musi odwrócić inną animowaną wartość do obliczeń. Przykładem jest odwrócenie skali (2x --> 0.5x):

const a = Animated.Value(1);
const b = Animated.divide(1, a);

Animated.spring(a, {
  toValue: 2,
}).start();

Wtedy b będzie podążać za animacją sprężynową a i generować wartość 1 / a.

Podstawowe użycie wygląda tak:

<Animated.View style={{transform: [{scale: a}]}}>
  <Animated.Image style={{transform: [{scale: b}]}} />
<Animated.View>

W tym przykładzie wewnętrzny obraz w ogóle się nie rozciągnie, ponieważ skalowanie rodzica zostaje skompensowane. Jeśli chcesz dowiedzieć się więcej, sprawdź przewodnik po animacjach.

Ciemne paski statusu​

Do StatusBar dodano nową wartość barStyle: dark-content. Dzięki temu możesz teraz używać barStyle zarówno na Androidzie, jak i iOS. Zachowanie będzie teraz następujące:

• default: Użyj domyślnych ustawień platformy (jasny na iOS, ciemny na Androidzie).

• light-content: Użyj jasnego paska statusu z czarnym tekstem i ikonami.

• dark-content: Użyj ciemnego paska statusu z białym tekstem i ikonami.

...i więcej​

To tylko próbka zmian w wersji 0.36. Sprawdź informacje o wydaniu na GitHubie, aby zobaczyć pełną listę nowych funkcji, poprawek błędów i zmian łamiących kompatybilność.

Możesz zaktualizować do wersji 0.36, uruchamiając następujące polecenia w terminalu:

$ npm install --save react-native@0.36
$ react-native upgrade