Cykl życia komponentu – PPwRJS #9

Różne okresy, takie same fazy

Po raz kolejny (i na pewno nie ostatni) skorzystam z pomocy niezastąpionego Dana Abramova.

Dan wydzielił trzy fazy wewnątrz każdego z okresów. Samych metod jest, aż 7. Część z nich należy do dwóch okresów. To dużo abstrakcji jak na jedno zagadnienie. Dołożyłem wszelkich starań, aby w zrozumiały sposób, nakreślić Ci jak to wygląda w praktyce.

Zacznijmy od charakterystyki poszczególnych okresów cyklu życia:

1. Mounting rozpoczyna się w momencie wywołania RenderDOM.render(). Jest to moment narodzin instancji komponentu. W oparciu o dostarczone props i bazowy stan zostanie wytworzona pierwsza wersja elementu React zwracanego przez komponent. Ten okres występuje tylko raz w cyklu życia komponentu.
2. Updating to najdłuższy okres w życiu każdego komponentu, powtarzany wielokrotnie. Zaczyna się przy pierwszej zmianie w props czy state, co zwykle następuje zaraz po zakończeniu Mounting. W tym okresie obsługujemy główne funkcje komponentu, aktualizujemy dane, reagujemy na działania użytkownika itd.
3. Unmounting następuje, gdy przyjdzie czas na pożegnanie się instancji z drzewem elementów. Zanim to nastąpi, należy zadbać o należyty porządek, co umożliwi sprawną pracę kolejnego pokolenia komponentów.

Teraz przejdźmy do wydzielonych przez Dana faz:

1. Render skupia metody czyste, pozbawione efektów ubocznych. Do ich obowiązków należy synchronizacja state z props i szeroko rozumiane przygotowanie komponentu do nadchodzącego renderowania. Metody render phase muszą być pozbawione efektów ubocznych, ich wywoływanie doprowadziłoby do ponownego rozpoczęcia całej fazy.
2. Pre-commit wypełnia krótki moment pomiędzy wywołaniem render a aktualizacją DOM. Możemy w tym czasie zapisać stan DOM przed aktualizacją, na wypadek gdybyśmy chcieli się do niego odwołać w commit phase.
3. Commit, ostatnia z faz, obejmuje wszystko co dzieje się po aktualizacji DOM. To najlepszy moment na wywoływanie skutków ubocznych (zapytania do serwera, aktualizacje stanu).

Zanim zaczniemy omawianie poszczególnych metod, małe sprostowanie. Na diagramie widzicie stan metod cyklu życia zgodny z wersją React 16.3. Jeżeli wcześniej korzystałeś z cyklu życia, to na pewno zauważyłeś nieobecność metod componentWillMount, componentWillReceiveProps i componentWillUpdate. Zostały wysłane na wycieczkę w jedną stronę do krainy deprecated. Niech spoczywają w spokoju, nie chcę poświęcać czasu na ich omawianie…

Jednak tak się składa, że metoda componentWillMount jest obecnie wykorzystywana w trackerze kryptowalut:

// App.js
state = {
	...,
	matchedCryptos: [],
	...
}

componentWillMount() {
  this.setMatchedCryptos();
}	

setMatchedCryptos = debounce(() => {
    const cryptos = [...this.state.cryptos];

    function isMatched(phrase) {
      const regex = new RegExp(`\\b${phrase}.*\\b`, 'i');
      return function(crypto) {
        return Object.values(crypto).some(val => regex.test(val));
      };
    }

    const isMatchedWithSearchQuery = isMatched(this.state.searchQuery);
    const matchedCryptos = cryptos.filter(isMatchedWithSearchQuery);
    this.setState({ matchedCryptos });
}, 250);

W dużym skrócie: w ten sposób dokonywałem inicjalizacji wartości tablicy matchedCryptos, wyświetlanej przez CoinList, przed pierwszym renderem. Początkowy stan searchQuery to '', więc wszystkie obiekty obecne w state.cryptos trafiały do matchedCryptos.

Poszukamy zastępstwa dla componentWillMount wśród metod, które ostały się po ostatniej aktualizacji. Zobaczymy, czy obejdzie się bez zmian w logice.

Metody cyklu życia

constructor(props) [Okres: Mounting, Faza: Render]

Metoda dobrze znana z klas ES6. W przypadku komponentów React, służy do inicjalizacji początkowego stanu i wiązania metod z instancją komponentu. Użycie constructora nie jest jedynym sposobem na poradzenie sobie z tymi obowiązkami. Sam chętnie korzystam z innego sposobu na inicjalizację początkowego stanu, czyli pól klas ES7. Z wiązaniami metod możemy sobie poradzić deklarując je jako funkcje strzałkowe. W ten sposób leksykalne wyszukiwanie this wykona pracę za nas. Z powodu tych alternatyw natkniesz się na wiele komponentów, w których na próżno szukać constructora.

Jeżeli zdecydujesz się na korzystanie z tej metody, musisz pamiętać o wywołaniu w jej wnętrzu super(props). Dzięki temu props zostaną przekazane do React.Component, abstrakcyjnej klasy bazowej, którą rozszerza każdy komponent klasowy. React.Component wiąże props z instancją, co pozwala na odwoływanie się do tego obiektu za pomocą this.props w całym jej wnętrzu.

Co robimy w constructor?

• Obowiązkowo wywołujemy super(props)
• Inicjalizujemy stan komponentu (this.state = { ... })
• Wiążemy metody z instancją komponentu

Czego nie robimy?

• Wywołujemy efekty uboczne (AJAX, subskrypcje zdarzeń, dispatchowanie akcji)
• Aktualizujemy stan przy pomocy this.setState()

Czy constructor to dobre zastępstwo dla componentWillMount? Niestety nie. Poprawna inicjalizacja w constructorze ogranicza się przypisywania wartości do literału obiektu (this.state = { ... }). Wywoływanie this.setState() nie wchodzi w grę. Szukamy dalej.

static getDerivedStateFromProps(nextProps, prevState) [Okres: Mounting/Updating, Faza: Render]

Jedna z dwóch nowych metod, wprowadzonych w aktualizacji 16.3. Występuje zarówno w okresie Mounting jak i Updating. Wywołuje ją przybycie do komponentu nowych propsów. W gDSFP porównujemy nowe propsy z dotychczasowym state. W ten sposób możemy zadecydować czy warto synchronizować stan przed renderem. gDSFP jest metodą statyczną, co wiąże się z brakiem dostępu do this wskazującego na instancję. Synchronizację stanu reprezentujemy za pomocą obiektu, który zwracamy, zamiast przekazywać go do this.setState().

Co robimy w getDerivedStateFromProps?

• Synchronizujemy state z nowymi propsami

Czego nie robimy?

• Wywołujemy efekty uboczne

Zastępstwo czy emerytura

„Krótki” przegląd metod cyklu życia za nami. Wygląda na to, że żadna z metod okresu Mounting nie nadaje się do ustawienia początkowego stanu this.state.matchedCryptos za pośrednictwem wywołania this.setMatchedCryptos(). Wniosek jest prosty: trzeba zrezygnować z takiej logiki. Zmienimy wyjściowy stan matchedCryptos na null zamiast []. Ten sam efekt, co poprzednio, (cryptos === this.state.cryptos przy pierwszym renderze) otrzymamy za pomocą następującej zmiany:

// Wcześniej
<CoinList cryptos={this.state.matchedCryptos} />
	
// Teraz
<CoinList cryptos={this.state.matchedCryptos !== null ? this.state.matchedCryptos : this.state.cryptos} />

Takie rozwiązanie nie zostanie z nami na długo. Kolejny wpis przyniesie kolejną przebudowę trackera. Wszystko za sprawą AJAX i pozyskiwania danych w czasie rzeczywistym z zewnętrznego API.

Goodies

Zanim rozstaniemy się z cyklem życia, mam dla Was trochę ekstrasów: