5 typowych praktyk, które możesz przestać robić w React

1. Optymalizacja Reakcja od samego początku
2. Renderowanie po stronie serwera dla SEO
3. Style inline i import CSS
4. Zagnieżdżony operator trójskładnikowy
5. Zamknięcia w React
6. Wniosek

W tym momencie trudno twierdzić, że React jest jedną z najbardziej kochanych bibliotek na świecie. React cieszy się ogromnym zainteresowaniem, a nowi programiści wpadają na platformę ze względu na swoje podejście do interfejsu użytkownika. I chociaż zarówno biblioteka, jak i cały ekosystem React dojrzewają przez lata, istnieją pewne przypadki, w których pytasz „jaki jest właściwy sposób, aby to dokładnie zrobić?”

I to jest uczciwe pytanie, które należy zadać - nie zawsze istnieje mocny „właściwy” sposób działania. W rzeczywistości, jak już zapewne wiesz, czasami najlepsze praktyki nie są tak świetne. Niektóre z nich mogą zagrozić wydajności, czytelności i na dłuższą metę sprawić, że wszystko będzie bezproduktywne.

W tym artykule opiszę 5 ogólnie przyjętych praktyk programistycznych, których można w rzeczywistości uniknąć podczas używania React. Oczywiście wyjaśnię, dlaczego uważam praktykę za możliwą do uniknięcia i sugeruję alternatywne podejścia, które pozwolą ci osiągnąć to samo.

Optymalizacja Reakcja od samego początku

Programiści z React włożyli wiele wysiłku, aby React szybko i nowe optymalizacje zostały dodane do miksu po każdej nowej aktualizacji. Moim zdaniem nie powinieneś tracić czasu na optymalizację rzeczy, dopóki nie zobaczysz rzeczywistych trafień wydajności.

Czemu?

Łatwiej jest skalować React w porównaniu z innymi platformami frontowymi, ponieważ nie trzeba przepisywać całych modułów, aby przyspieszyć działanie. Zwykłym sprawcą powodującym problemy z wydajnością jest proces uzgadniania, którego React używa do aktualizacji wirtualnego DOM.

Przyjrzyjmy się, jak React radzi sobie z rzeczami pod maską. Na każdym renderie () React generuje drzewo składające się z elementów interfejsu użytkownika - węzły liści są rzeczywistymi elementami DOM. Gdy stan lub rekwizyty zostaną zaktualizowane, React musi wygenerować nowe drzewo z minimalną liczbą zmian i zachować przewidywalność.

Wyobraź sobie, że masz drzewo, które wygląda tak:

Wyobraź sobie, że aplikacja otrzymuje nowe dane i należy zaktualizować następujące węzły:

Reakcja zazwyczaj kończy się ponownym renderowaniem całego poddrzewa zamiast renderowania tylko odpowiednich węzłów takich jak ten:

Gdy stan zmienia się w komponentach najwyższego rzędu, wszystkie składniki poniżej są ponownie renderowane. To jest domyślne zachowanie i jest w porządku dla małych aplikacji. W miarę rozwoju aplikacji należy rozważyć pomiar rzeczywistej wydajności za pomocą narzędzi do profilowania Chrome. Narzędzie zapewni precyzyjne informacje o czasie marnowanym na niechciane rendery. Jeśli liczby są znaczące, możesz zoptymalizować czas renderowania, dodając do komponentu hak shouldComponentUpdate.

Hak zostaje wyzwolony przed rozpoczęciem procesu ponownego renderowania i domyślnie zwraca wartość true:

Gdy zwraca true, algorytm różnicowania React przejmuje i ponownie renderuje całe poddrzewo. Możesz tego uniknąć, dodając logikę porównania do updateComponentUpdate i aktualizując logikę tylko wtedy, gdy odpowiednie rekwizyty uległy zmianie.

Komponent nie zostanie zaktualizowany, jeśli zmieniły się inne rekwizyty / stany z wyjątkiem koloru / liczby.

Poza tym istnieją pewne sztuczki optymalizacyjne, które zazwyczaj nie są dostępne dla programistów, ale mają wpływ na wydajność aplikacji.

Wymieniłem niektóre z możliwych do uniknięcia nawyków i poniższe rozwiązania:

1. Niezoptymalizowane obrazy - jeśli budujesz na dynamicznych obrazach, musisz rozważyć opcje podczas pracy z obrazami. Obrazy o dużych rozmiarach plików mogą sprawiać użytkownikowi wrażenie, że aplikacja działa powoli. Kompresuj obrazy, zanim wciśniesz je na serwer lub użyj a dynamiczna manipulacja obrazem rozwiązanie zamiast tego. Osobiście lubię Cloudinary, aby zoptymalizować obrazy reakcji, ponieważ ma swoją własną bibliotekę reagowania, ale zamiast tego możesz użyć Amazon S3 lub Firebase.
2. Nieskompresowane pliki kompilacji - pliki kompilacji Gzipping (bundle.js) mogą znacznie zmniejszyć rozmiar pliku. Będziesz musiał zmodyfikować konfigurację serwera WWW. Webpack ma wtyczkę kompresji gzip znaną jako plugin kompresji-webpack . Możesz użyć tej techniki do wygenerowania bundle.js.gz podczas kompilacji.

Renderowanie po stronie serwera dla SEO

Chociaż aplikacje na jednej stronie są niesamowite, istnieją dwie kwestie, które wciąż są im przypisywane.

1. Gdy aplikacja ładuje się początkowo, w przeglądarce nie ma pamięci podręcznej JavaScript. Jeśli aplikacja jest duża, czas potrzebny na początkowe załadowanie aplikacji będzie również ogromny.
2. Ponieważ aplikacja jest renderowana po stronie klienta, roboty indeksujące używane przez wyszukiwarki nie będą mogły indeksować treści generowanych przez JavaScript. Wyszukiwarki zobaczą, że twoja aplikacja jest pusta, a następnie źle oceniam.

W tym miejscu przydatna jest technika renderowania po stronie serwera. W SSR treść JavaScript jest początkowo renderowana z serwera. Po początkowym renderowaniu skrypt po stronie klienta przejmuje kontrolę i działa jak normalne SPA. Złożoność i koszty związane z konfiguracją tradycyjnego SSR są wyższe, ponieważ trzeba użyć serwera Node / Express.

Jest dobra wiadomość, jeśli korzystasz z SEO, indeksuje Google i indeksuje zawartość JavaScript bez żadnych problemów. Google faktycznie zaczął indeksować materiał JavaScript w 2016 r., A algorytm działa teraz bez zarzutu.

Oto fragment bloga dla webmasterów w październiku 2015 r.

Jeśli jednak robisz to, aby poprawić początkową szybkość renderowania, powinieneś spróbować łatwiejszej implementacji SSR przy użyciu biblioteki takiej jak Next.js. Next oszczędza czas, który w przeciwnym razie poświęciłbyś na konfigurację serwera Node / Express.

Style inline i import CSS

Podczas pracy z React osobiście próbowałem różnych pomysłów stylizacyjnych, aby znaleźć nowe sposoby wprowadzania stylów do komponentów React. Tradycyjne podejście CSS-in-CSS, które istnieje od dziesięcioleci, współpracuje z komponentami React. Wszystkie arkusze stylów trafiłyby do katalogu arkuszy stylów, a następnie można zaimportować wymagany CSS do komponentu.

Jednak podczas pracy z komponentami arkusze stylów nie mają już sensu. Podczas gdy React zachęca do myślenia o aplikacji w kategoriach komponentów, arkusze stylów zmuszają Cię do myślenia o tym na poziomie dokumentu.

Stosowane są różne inne podejścia do łączenia kodu CSS i JS w jeden plik. Styl Inline jest prawdopodobnie najbardziej popularny wśród nich.

Nie musisz już importować CSS, ale rezygnujesz z czytelności i łatwości konserwacji. Poza tym style Inline nie obsługują zapytań o media, pseudo klas i pseudoelementów ani stylów. Oczywiście, są hacki, które pozwalają ci na wykonanie niektórych z nich, ale to nie jest takie wygodne.

To właśnie przydaje się CSS-in-JSS, a style Inline nie są dokładnie CSS-in-JSS. Poniższy kod demonstruje koncepcję za pomocą stylizowanych komponentów.

To, co widzi przeglądarka, to coś takiego:

Nowy tag <style> jest dodawany na górze DOM iw przeciwieństwie do stylów wbudowanych, generowane są tutaj rzeczywiste style CSS. Tak więc wszystko, co działa w CSS, działa również w stylizowanych komponentach. Ponadto technika ta poprawia CSS, poprawia czytelność i pasuje do architektury komponentu. Z biblioteką styled-components również otrzymujesz wsparcie SASS, które zostało dołączone do biblioteki.

Zagnieżdżony operator trójskładnikowy

Operatorzy trójskładni są popularni w React. Jest moim operatorem do tworzenia instrukcji warunkowych i działa świetnie w metodzie render (). Na przykład pomagają renderować elementy w linii w poniższym przykładzie, użyłem ich do wyświetlenia statusu logowania.

Jednak gdy zagnieżdżamy operatorów trójskładnikowych w kółko, mogą one stać się brzydkie i trudne do odczytania.

Jak widać, skrócone notacje są bardziej zwarte, ale powodują, że kod wydaje się nieporządny. Teraz zrób zdjęcie, jeśli masz w swojej strukturze kilkanaście zagnieżdżonych trójskładników. I zdarza się to często, niż myślisz. Gdy zaczniesz od operatorów warunkowych, łatwo jest go zagnieżdżać, aż w końcu dojdziesz do punktu, w którym zdecydujesz, że potrzebujesz lepszej techniki do obsługi renderowania warunkowego.

Ale dobrą rzeczą jest to, że masz wiele opcji do wyboru. Możesz użyć wtyczki babel, takiej jak JSX Control Statements, która rozszerza JSX o komponenty dla instrukcji warunkowych i pętli.

Jest jeszcze jedna popularna technika zwana iify (IIFE - wyrażenia funkcji wywoływane natychmiastowo). Jest to funkcja anonimowa, która jest wywoływana natychmiast po ich zdefiniowaniu.

Zawinęliśmy funkcję w parę nawiasów, aby funkcja anonimowa była wyrażeniem funkcji. Ten wzorzec jest popularny w JavaScript z wielu powodów. Ale w React możemy umieścić wszystkie instrukcje if / else wewnątrz funkcji i zwrócić wszystko, co chcemy renderować.

Oto przykład, który pokazuje, w jaki sposób wykorzystamy IFFE w React.

IIFE mogą mieć wpływ na wydajność, ale w większości przypadków nie będzie to nic znaczącego. Istnieje więcej metod uruchamiania instrukcji warunkowych w React i omówiliśmy to w 8 metod warunkowego renderowania w React .

Zamknięcia w React

Zamknięcia są funkcjami wewnętrznymi, które mają dostęp do zmiennych i parametrów funkcji zewnętrznej. Zamknięcia są wszędzie w JavaScript i prawdopodobnie korzystałeś z niego nawet, jeśli jeszcze tego nie zrobiłeś.

Ale kiedy używasz zamknięć wewnątrz metody render (), to jest naprawdę źle. Za każdym razem, gdy renderowany jest komponent SayHi, tworzona jest nowa funkcja anonimowa i przekazywana do komponentu Button. Chociaż rekwizyty się nie zmieniły, <Button /> będzie zmuszony do ponownego renderowania. Jak wcześniej wspomniano, zmarnowane renderowania mogą mieć bezpośredni wpływ na wydajność.

Zamiast tego zamień zamknięcia metodą klasową. Metody klas są bardziej czytelne i łatwe do debugowania.

Wniosek

Kiedy platforma rośnie, każdego dnia pojawiają się nowe wzory. Niektóre wzorce pomagają poprawić ogólny przepływ pracy, podczas gdy inne mają znaczące skutki uboczne. Gdy efekty uboczne wpływają na wydajność aplikacji lub jej czytelność, prawdopodobnie lepszym pomysłem jest poszukiwanie alternatyw. W tym poście omówiłem niektóre praktyki React, których można uniknąć z powodu ich niedociągnięć.

Jakie są twoje przemyślenia na temat Reactu i najlepszych praktyk w React? Udostępnij je w komentarzach.