Learn by failing

Błędy i wnioski wyciągnięte po 2 latach pracy z React

Bartosz Szczeciński

20.02.2019

@btmpl

medium.com/@baphemot

https://szczecinski.eu

O mnie

- PHP dev -> JS dev, ponad 17 lat doświadczenia

- Administrator Reactiflux

- Technical writer

- React Evangelist

O projekcie

- zadanie: przepisać monolityczną aplikację wykonaną w JSP na React

- początek: październik 2016

- migracja w etapach - use-case po use-case

W liczbach

- 9 połączonych projektów

- 40+ FE developerów, 5 krajów, 2 strefy czasowe

- największy zespół: 11 FE developerów

Dynamiczny rozwój

- brak wzorców i wytycznych narzuconych przez React jest zarówno polem popisu dla architektów, jak i pułapką dla developerów

- ciągła ewolucja możliwości, dobrych praktyk oznacza, że kod dużo szybciej staje się "legacy"

  mixins -> HoC -> render props -> React Hooks ...?

Szum komunikacyjny / FUD

Mnogość wyboru

O ile React jest naszym podstawowym wyborem, o tyle biblioteki "dodatkowe" przychodzą i odchodzą wraz z supportem i oczekiwaniami społeczności

  react-test-utils -> Enzyme -> react-testling-library

  react-router -> @reach/router? navi?

  react-datepicker -> react-dates

  lodash -> ESNext

Trendy

Rozwiązanie CSS ewoluowało wraz z projektem

- pliki .css - problem z generowaniem CSS (zagnieżdżenia)

- pliki .less i CSS modules - problem z nadpisywaniem styli

- styled-components - problemy z tworzeniem zbyt dużej ilości komponentów (divitis)

Zmiany decyzji

Zewnętrzne biblioteki:

- proof of concept - zebranie pełnych wymagań od Product Ownera i wykonanie PoC dostępnych bibliotek; zestawienie za i przeciw - po roku zmiana wymagań...

- abstrakcje - tworząc komponenty pośrednie, eksponujące tylko tą część API, którą potrzebujemy, umożliwiamy zmianę implementacji bez przepisywania aplikacji

Mnogość danych

Zewnętrzne dane:

Praca z nieustannie zmieniającym się API (również przepisywanym z monolitu na MS). Ciągłe modyfikowanie API komponentów / kształtu Redux store.

Testy

- 75% test coverage = pisz głupie testy byle tylko podnieść coverage%

- testowanie nie tego co trzeba

Testy

- archaiczny stack (karma + mocha + chai + chrome) = słaba wydajność, błędy w coverage, długie czasy działania uniemożliwiają TDD

Testy

react-testing-library

"ograniczone" Enzyme wymuszające dobre praktyki

Testy

Zmiana stacku:

- jest

- js-dom

- jeszcze trochę chai (spy)

Benefity:

- testy działają 10 razy szybciej

- testy w js-dom = nie uruchamiasz Chrome = 2GB wolnego

- watch mode

- refactoring = <3

Walka z narzędziami

- globalne (na całą organizację) wymagania dot. standardu kodu oznaczają walkę z niektórymi zwyczajami w JS:

  - inny układ klamer (one true brace style),

  - długość linijki (java)

  - nazwy modułów

- utrudnianie życia

  developerowi

Przydatne narzędzia

Prettier

Husky

Optymalizacja aplikacji

- 9+ oddzielnych aplikacji

- 2+ widgety

- każde z nich może być

  uruchamiane niezależnie

  lub wraz z innymi aplikacjami

  na tej samej stronie WWW

Współdzielenie kodu

- 9+ aplikacji = 9 oddzielnych chunków z Reactem

- 2+ widgety = 2 dodatkowe chunki z Reactem

  3+ pliki .js z tym samym kodem na każdej stronie

Webpack DllPlugin

Analiza plików aplikacji

Duża ilość komponentów

- wiele aplikacji = wiele komponentów

- wiele komponentów w wielu aplikacjach = więcej miejsc

  do sprawdzenia czy "ktoś nie zrobił już guzika?"

- więcej wersji guzika = legacy code = większy koszt

  utrzymania

Zapomnij o /src/components

"Komponenty utworzone w katalogu /src/components to komponenty, których nie miałem jeszcze czasu wrzucić do NPM"

- Abraham Lincoln, 2018

Własne repozytoria

Dokumentowanie

Dokumentowanie

Bycie na bieżąco

Technologia nie stoi w miejscu, a kto nie idzie do przodu ten się cofa.

W jaki sposób wprowadzać nowe technologie i rozwiązania na projekcie, w którym pracuje wiele developerów o różnym poziomie wiedzy?

Bycie na bieżąco

Proof of Concept

- wykaż, jakie plusy przyniesie zmiana technologii / procesu

  - dla Product Ownera ("szybciej, taniej, mniej błędów")

  - dla użytkowników ("szybciej, częściej, łatwiej")

  - dla developerów ("mniej fuckupów, mniej boilerplate")

- wykaż, jak zmieni się kod na skutek wprowadzenia

  Twojej sugestii

  - screenshot z diff przed i po

  - ilość kodu, którego nie trzeba będzie pisać

Bycie na bieżąco

Workshop i knowledge-sharing

- jeżeli to możliwe, organizuj wewnętrzne szkolenia dla

  developerów

- wsparcie w onboardingu dla nowych członków zespołów

- dokumentacja, komentarze, code review

- knowledge-sharing poza zespół

Bycie na bieżąco

Samodoskonalenie

- obserwuj i otaczaj się ludźmi mądrzejszymi i DUŻO mądrzejszymi od ciebie; zwalcz syndrom impostora

- śledź nowinki

  - This Week in React

    https://reactstaticpodcast.netlify.com/episode/week0

  - This Week in /Reactjs

    https://reactstaticpodcast.netlify.com/episode/week0/

  - React Polska

    https://facebook.com/profile.php?id=972937362726271

  - Reactiflux

    https://www.reactiflux.com/

Eksperymentuj!

Nawet jeżeli to co napiszesz

jest tak złe, że Dan w skali "how bad is it" ocenia to na "11/10" to nauczyłeś się czegoś nowego.