DEV Community: Bartosz Zagrodzki

Jak zoptymalizować React Context?

Bartosz Zagrodzki — Sun, 20 Feb 2022 13:28:01 +0000

Przetłumaczona wersja artykułu Kenta C. Doddsa

NOTKA: Zanim zaczniemy, chciałbym mieć pewność, że wiesz, kiedy Twój kontekst wymaga optymalizacji:

Wartości często się zmieniają.

Twój kontekst ma wielu konsumentów.

Zawracasz sobie głowę używaniem React.memo.

Po zmierzeniu wydajności, dochodzisz do wniosku, że potrzebujesz optymalizacji.

Jeśli te punkty opisują Twoją sytuację, czytaj dalej (nie przegap alternatywnego rozwiązania, które prawdopodobnie jest lepsze). W rzeczywistości jest ono znacznie lepsze, przerobiłem nawet ten post, by to pokazać. Jeśli chcesz zobaczyć moją poprzednią rekomendację, zajrzyj tutaj.

Uwierz mi, jeśli zamierzasz to zrobić tylko dlatego, że uważasz swój kod za zbyt wolny, nie przejmuj się. Nie żartuję. React jest naprawdę szybki, a dodanie złożoności w imię wydajności, gdy ta nie jest taka zła, po prostu marnuje Twój "budżet złożoności".

Najprostszym rozwiązaniem, by zoptymalizować kontekst jest użycie hooka useReducer zamiast useState oraz umieszczenie stanu w jednym dostawcy, a funkcji dispatch w drugim:

Nie tylko nie musisz używać w tym przypadku useMemo, ale również unikasz ponownego renderowania komponentów używających kontekstu:

Działa to tak samo, jak w przypadku mojego oryginalnego rozwiązania z useMemo, z wyjątkiem tego, że kontekst komponentu <Counter /> nie jest aktualizowany, przez co unikamy całkowicie ponownego renderowania.

Osobiście uważam, że jest to bardziej skomplikowane API, niż mogłoby być, dlatego w większości przypadków nie przejmowałbym się optymalizacją kontekstu. Ale jeśli naprawdę tego potrzebujesz, zrób to tak, by jak najprościej obejść problem.

Rozdzielenie stanu i `dispatch` bywa irytujące

Niektórzy uważają to za denerwujące:

const state = useCountState()
const dispatch = useCountDispatch()

Mówią: "nie można tego zrobić po prostu tak?"

const [state, dispatch] = useCount()

Oczywiście, że można:

function useCount() {
  return [useCountState(), useCountDispatch()]
}

Pamiętaj tylko, że każdy komponent używający tego, traci korzyści związane z wydajnością, jeśli tak naprawdę potrzebuje jednej z tych rzeczy.

Sprawdź również: React Context - jak efektywnie go używać?

Testy statyczne vs jednostkowe vs E2E w aplikacjach frontendowych

Bartosz Zagrodzki — Mon, 11 Oct 2021 13:08:21 +0000

Przetłumaczona wersja artykułu Kenta C. Doddsa

W moim wywiadzie "Praktyki testowania z J. B. Rainsbergerem dostępnym na TestingJavaScript.com usłyszałem coś takiego:

"Możesz rzucać farbą o ścianę pokrywając dużą jej część, ale dopóki nie użyjesz pędzla nie pokryjesz narożników. 🖌️"

Uwielbiam tę metaforę w odniesieniu do testowania, ponieważ zasadniczo mówi ona, że wybór odpowiedniej strategii testowania jest tym samym rodzajem wyboru, jakiego dokonujesz wybierając pędzel do malowania ściany. Czy na całej ścianie użyłbyś pędzelka o cienkim włosiu? Oczywiście, że nie. Zajęłoby to mnóstwo czasu, a efekt końcowy pewnie i tak nie byłby zadowalający. Czy użyłbyś wałka, aby pomalować wszystko, łącznie z zamontowanymi meblami, które twoja praprababka przywiozła zza oceanu dwieście lat temu? Nie ma mowy. Istnieją różne pędzle do różnych sytuacji, dokładnie tak jak w przypadku testów.

Dlatego stworzyłem Trofeum Testów (The Testing Trophy). W międzyczasie Maggie Appleton (autorka mistrzowskiego designu egghead.io) stworzyła tą grafikę dla TestingJavaScript.com:

Wyróżniamy tutaj 4 typy testów. Powyższa grafika wszystko pokazuje, ale dla tych używających czytników ekranu (lub tych, którym obraz się nie załadował) opiszę wszystko poniżej:

End to End: robot, który używa strony jak użytkownik, klika i sprawdza, czy wszystko działa. Czasami nazywane „testami funkcjonalnymi” lub e2e.
Integracyjne: weryfikują, czy kilka pojedynczych elementów wspólnie dobrze działa.
Jednostkowe: sprawdzają pojedyncze elementy naszej aplikacji.
Statyczne: wyłapują literówki i inne błędy w trakcie pisania kodu.

Rozmiar poszczególnych poziomów nie jest przypadkowy, zależy od stopnia skupienia się na nich podczas testowania aplikacji (ogólnie). Chcę bardziej wyjaśnić te różne formy testowania, jak używa się ich w praktyce i co możemy zrobić aby zwiększyć pewność jaką mogę one nam dać.

Typy testów

Spójrzmy na kilka przykładów tego rodzaju testów, idąc od góry do dołu:

End to End

Zazwyczaj uruchamiają one całą aplikację (zarówno frontend, jak i backend), a Twój test będzie działał z aplikacją tak, jak zrobiłby to typowy użytkownik. Przykład technologii: Cypress

import {generate} from 'todo-test-utils'

describe('todo app', () => {
  it('should work for a typical user', () => {
    const user = generate.user()
    const todo = generate.todo()
    // będziemy tutaj przechodzić przez proces rejestracji.
    // Zazwyczaj mamy tylko jeden taki test.
    // pozostałe testy będą korzystać z tego samego endpoint-u
    // co aplikacja, więc pomożemy pominąć nawigację w tym środowisku
    cy.visitApp()

    cy.findByText(/register/i).click()

    cy.findByLabelText(/username/i).type(user.username)

    cy.findByLabelText(/password/i).type(user.password)

    cy.findByText(/login/i).click()

    cy.findByLabelText(/add todo/i)
      .type(todo.description)
      .type('{enter}')

    cy.findByTestId('todo-0').should('have.value', todo.description)

    cy.findByLabelText('complete').click()

    cy.findByTestId('todo-0').should('have.class', 'complete')
    // itp...
    // Moje testy E2E zazwyczaj symulują prawdziwe zachowanie użytkownika.
    // Czasami mogą być naprawdę długie.
  })
})

Integracyjne

Test poniżej renderuje całą aplikację. NIE jest to wymagane w testach integracyjnych, a większość moich testów tego nie robi. Będą jednak renderowane ze wszystkimi dostawcami używanymi w aplikacji (to właśnie robi metoda render z wyimaginowanego modułu „test/app-test-utils”). Ideą testów integracyjnych jest, by jak najmniej używać mocków. Mockuję tylko:

Żądania sieciowe (używając MSW)
Komponenty odpowiedzialne za animacje (kto chciałby na to czekać podczas testu?)

import * as React from 'react'
import {render, screen, waitForElementToBeRemoved} from 'test/app-test-utils'
import userEvent from '@testing-library/user-event'
import {build, fake} from '@jackfranklin/test-data-bot'
import {rest} from 'msw'
import {setupServer} from 'msw/node'
import {handlers} from 'test/server-handlers'
import App from '../app'

const buildLoginForm = build({
  fields: {
    username: fake(f => f.internet.userName()),
    password: fake(f => f.internet.password()),
  },
})

// testy integracyjne zazwyczaj mockują tylko żądania HTTP za pomocą MSW
const server = setupServer(...handlers)

beforeAll(() => server.listen())
afterAll(() => server.close())
afterEach(() => server.resetHandlers())

test(`logging in displays the user's username`, async () => {
  // Customowy render zwraca obietnicę, która zostaje rozwiązana po 
  //   zakończeniu ładowania aplikacji (jeśli renderujesz po stronie serwera, możesz tego nie potrzebować).
  // Customowy render umożliwia Ci również ustawienie początkowej ścieżki
  await render(<App />, {route: '/login'})
  const {username, password} = buildLoginForm()

  userEvent.type(screen.getByLabelText(/username/i), username)
  userEvent.type(screen.getByLabelText(/password/i), password)
  userEvent.click(screen.getByRole('button', {name: /submit/i}))

  await waitForElementToBeRemoved(() => screen.getByLabelText(/loading/i))

  // potwierdź wszystko, czego potrzebujesz, aby sprawdzić, czy użytkownik jest zalogowany
  expect(screen.getByText(username)).toBeInTheDocument()
})

W tym celu zazwyczaj mam również kilka rzeczy skonfigurowanych globalnie, takich jak automatyczne resetowanie wszystkich mocków między testami.

Dowiedz się jak skonfigurować plik konfiguracyjny test-utils, taki jak ten powyżej w dokumentacji biblioteki React Testing Library

Jednostkowe

import '@testing-library/jest-dom/extend-expect'
import * as React from 'react'
// jeśli masz moduł test-utils, jak w przykładzie powyżej
// użyj zamiast niego @testing-library/react
import {render, screen} from '@testing-library/react'
import ItemList from '../item-list'

// Niektórzy nie nazywają tego testem jednostkowym, ponieważ renderujemy do DOM za pomocą Reacta.
// Powiedzieliby, żebyś zamiast tego używał renderowania płytkiego.
// Kiedy ci to powiedzą, wyślij ich na https://kcd.im/shallow
test('renders "no items" when the item list is empty', () => {
  render(<ItemList items={[]} />)
  expect(screen.getByText(/no items/i)).toBeInTheDocument()
})

test('renders the items in a list', () => {
  render(<ItemList items={['apple', 'orange', 'pear']} />)
  // note: w przypadku czegoś tak prostego mógłbym rozważyć użycie snapshot-a, ale tylko wtedy, gdy:
  // 1. snapshot jest mały
  // 2. używamy toMatchInlineSnapshot()
  // Dowiedz się więcej: https://kcd.im/snapshots
  expect(screen.getByText(/apple/i)).toBeInTheDocument()
  expect(screen.getByText(/orange/i)).toBeInTheDocument()
  expect(screen.getByText(/pear/i)).toBeInTheDocument()
  expect(screen.queryByText(/no items/i)).not.toBeInTheDocument()
})

Wszyscy nazywają to testem jednostkowym i mają rację:

// "czyste" funkcje są NAJLEPSZE do testów jednostkowych, KOCHAM używanie do nich biblioteki jest-in-case!
import cases from 'jest-in-case'
import fizzbuzz from '../fizzbuzz'

cases(
  'fizzbuzz',
  ({input, output}) => expect(fizzbuzz(input)).toBe(output),
  [
    [1, '1'],
    [2, '2'],
    [3, 'Fizz'],
    [5, 'Buzz'],
    [9, 'Fizz'],
    [15, 'FizzBuzz'],
    [16, '16'],
  ].map(([input, output]) => ({title: `${input} => ${output}`, input, output})),
)

Statyczne

// dostrzegasz błąd?
// założę się, że ESLint
// wyłapie to szybciej niż Ty w code review 😉
for (var i = 0; i < 10; i--) {
  console.log(i)
}

const two = '2'
// ok, ten przykład jest trochę wymyślony,
// ale TypeScript zwróci Ci uwagę na błąd:
const result = add(1, two)

Dlaczego testujemy ponownie?

Myślę, że ważne jest, aby pamiętać, dlaczego w ogóle piszemy testy. Dlaczego piszesz testy? Czy to dlatego, że ci kazałem? Czy to dlatego, że Twój PR bez testów zostanie odrzucony? Czy to dlatego, że testowanie usprawnia workflow?

Największym i najważniejszym powodem, dla którego piszę testy jest PEWNOŚĆ. Chcę być pewny, że kod, który piszę na przyszłość, nie zepsuje aplikacji, którą mam obecnie uruchomioną w środowisku produkcyjnym. Więc cokolwiek robię, chcę mieć pewność, że rodzaje testów, które piszę, dadzą mi największą możliwą pewność siebie i muszę być świadomy kompromisów, których dokonuję podczas testowania.

Porozmawiajmy o kompromisach

Jest kilka ważnych elementów trofeum testów, które chcę przedstawić na tym zdjęciu (wyrwanym z moich slajdów):

Strzałki na obrazku oznaczają trzy kompromisy, jakie podejmujesz podczas pisania testów automatycznych:

Koszt: ￠heap ➡ 💰🤑💰

W miarę przesuwania się w górę trofeum testy stają się coraz bardziej kosztowne. Odbija się to na rzeczywistych kosztach testów w środowisku CI, ale także na czasie potrzebnym na napisanie i utrzymanie każdego indywidualnego testu.

Im wyżej jesteśmy (w trofeum testów), tym więcej jest punktów niepowodzenia, a zatem tym bardziej prawdopodobne jest, że test się wysypie, co prowadzi do większej ilości czasu potrzebnego na analizę i naprawę. Pamiętaj o tym, to ważne #zapowiedz...

Prędkość: 🏎💨 ➡ 🐢\

Im wyżej w trofeum tym testy zwykle przebiegają wolniej. Wynika to z faktu, że Twój test wykonuje coraz więcej kodu. Testy jednostkowe zazwyczaj testują coś małego, co nie ma zależności lub mockują te zależności (skutecznie zamieniając tysiące wierszy kodu na kilka linii). Pamiętaj o tym, to ważne #zapowiedz...

Pewność: Proste sprawy 👌 ➡ Duże problemy 😖

Kompromisy w zakresie kosztów i szybkości są zwykle przywoływane, gdy ludzie mówią o piramidzie testów 🔺. Gdyby to były jedyne kompromisy, skupiłbym 100% swoich wysiłków na testach jednostkowych i całkowicie zignorował wszelkie inne formy testowania w odniesieniu do piramidy testowej. Oczywiście nie powinniśmy tego robić, a to z powodu jednej bardzo ważnej zasady, o której prawdopodobnie słyszałeś już wcześniej:

"Im bardziej Twoje testy przypominają sposób korzystania z oprogramowania, tym większą pewność mogą Ci dać."

Co to znaczy? Oznacza to, że nie ma lepszego sposobu, aby upewnić się, że Twoja ciocia Marie będzie mogła rozliczać podatki za pomocą Twojego oprogramowania podatkowego, niż faktyczne wykonanie tego rozliczenia. Ale nie chcemy czekać, aż ciocia Marie znajdzie dla nas bugi, prawda? Zajęłoby to zbyt długo i prawdopodobnie i tak przegapiłaby ona niektóre funkcje, które powinniśmy przetestować. W połączeniu z faktem, że regularnie publikujemy aktualizacje naszego oprogramowania, nie ma mowy, aby jakakolwiek liczba ludzi była w stanie za tym nadążyć.

Więc co robimy? Idziemy na kompromis. Jak? Piszemy oprogramowanie testujące nasze oprogramowanie. A kompromis, na który zawsze musimy się zgodzić, polega na tym, że nasze testy nie przypominają sposobu, w jaki nasze oprogramowanie jest używane tak niezawodnie, jak wtedy, gdy testowała je ciocia Marie. Ale robimy to, ponieważ dzięki takiemu podejściu rozwiązujemy realne problemy. Postępujemy tak na każdym etapie trofeum testów.

Wspinając się w górę trofeum testowego, zwiększasz to, co nazywam "współczynnikiem ufności". Jest to względna pewność, że każdy test może doprowadzić Cię do tego poziomu. Możesz sobie wyobrazić, że nad trofeum znajduje się testowanie ręczne. Takie testowanie dałoby Ci największą pewność, ale byłoby bardzo drogie i wolne.

Wcześniej wspominałem, byś zapamiętał dwie rzeczy:

Im wyżej zajdziesz w hierarchii testów, tym więcej jest punktów niepowodzenia, a zatem tym większe prawdopodobieństwo, że test się wysypie

Testy jednostkowe zazwyczaj testują coś małego, co nie ma
zależności lub będzie mockować te zależności (skutecznie zamieniając tysiące wierszy kodu na kilka).

Mówią one, że im niżej jesteś w trofeum, tym mniej kodu jest testowane. Będąc na niższym poziomie potrzebujesz większej liczby testów, by obsłużyć tyle linii kodu, ile mógłby wykonać jeden test na wyższym poziomie. W rzeczywistości, gdy schodzisz w trofeum testów, są pewne rzeczy, których nie można przetestować.

W szczególności narzędzia do analizy statycznej nie są w stanie zapewnić zaufania do logiki biznesowej. Testy jednostkowe nie są w stanie zapewnić, że gdy wywołujesz zależność, robisz to właściwie (chociaż możesz tworzyć asercje dotyczące tego, jak jest wywoływana, nie możesz upewnić się, że jest wywoływana poprawnie za pomocą testu jednostkowego). Testy integracyjne UI nie dają pewności, że przekazujesz właściwe wartości na backend oraz czy poprawnie obsługujesz błędy. Testy End to End są całkiem sprawne, ale zazwyczaj będziesz je uruchamiał w nieprodukcyjnym środowisku (podobnym do produkcyjnego, ale nie produkcyjnym), aby wymienić pewność na praktyczność.

Spójrzmy na to z innej strony. Na szczycie trofeum testów, jeśli spróbujesz użyć testu E2E, aby sprawdzić, czy wpisując coś w określone pole i klikając przycisk związany z integracją między formularzem a generatorem adresów URL, wszystko działa prawidłowo, potrzebujesz uruchomić całą aplikację (w tym backend). To byłoby bardziej odpowiednie dla testu integracyjnego. Jeśli spróbujesz użyć takiego testu, by sprawdzić przypadek kalkulatora do wprowadzania kodu kuponu, prawdopodobnie dokonasz wielu operacji
w funkcji konfiguracyjnej, aby upewnić się, że możesz renderować komponenty korzystające z tego kalkulatora i obsłużyć ten przypadek w teście jednostkowym. Jeśli spróbujesz użyć testu jednostkowego, aby zweryfikować, co się stanie, gdy wywołasz funkcję add ze stringiem zamiast liczby, lepszym pomysłem będzie użycie statycznego narzędzia do sprawdzania typu, takiego jak TypeScript.

Wnioski

Każdy poziom wiążę się ze swoimi własnymi kompromisami. Test E2E ma więcej miejsc, w których może się nie powieść, co często utrudnia wyśledzenie kodu, który spowodował uszkodzenie, ale oznacza to również, że test daje większą pewność. Jest to szczególnie przydatne, jeśli nie masz wystarczająco dużo czasu na pisanie testów. Wolałbym zachować pewność i próbować znaleźć błąd, niż nie wyłapywać problemu za pomocą testu.

W końcu nie zależy mi na wyróżnieniach. Jeśli chcesz nazwać moje testy jednostkowe integracyjnymi lub nawet E2E (jak niektórzy ludzie to robią 🤷‍♂️), to niech tak będzie. Interesuje mnie to, czy mam pewność, że kiedy wysyłam zmiany, mój kod spełnia wymagania biznesowe i zastosuję tyle kombinacji różnych strategii testowania, ile będzie potrzebnych, aby osiągnąć cel.

Powodzenia!

pętla for vs chaining vs .reduce()

Bartosz Zagrodzki — Fri, 08 Oct 2021 15:38:51 +0000

Przetłumaczona wersja artykułu Kenta C. Doddsa

Jedną z operacji w trakcie przenoszenia mojego internetowego życia, było pobranie wszystkich zdjęć z Google Photos. Uznałem, że potrzebuję zmiany ich organizacji, toteż napisałem do tego prosty skrypt. To, co robił nie jest istotne dla tego artykułu, więc nie będę opisywał szczegółów (tutaj cała sytuacja, jeśli chcesz o tym poczytać). Oto fragment o którym chciałbym coś powiedzieć (zredagowany dla czytelności):

const lines = execSync(`find "${searchPath}" -type f`).toString().split('\n')

const commands = lines
  .map(f => f.trim())
  .filter(Boolean)
  .map(file => {
    const destFile = getDestFile(file)
    const destFileDir = path.dirname(destFile)
    return `mkdir -p "${destFileDir}" && mv "${file}" "${destFile}"`
  })

commands.forEach(command => execSync(command))

Zasadniczo wszystko, co się tutaj dzieje, to użycie polecenia find, aby znaleźć listę plików w katalogu, a następnie rozdzielenie wyniku na wiersze, pozbycie się białych znaków, mapowanie ich na polecenia, a później wykonanie tych poleceń.

Udostępniłem ten skrypt na Twitterze i kilka osób krytykowało to, że nie użyłem metody .reduce(). Jestem prawie pewien, że sugerowali to jako wskazówkę do optymalizacji, ponieważ możemy dzięki temu zmniejszyć liczbę pętli po tablicy.

Żeby było jasne, było tam około 50 tysięcy pozycji, więc zdecydowanie więcej, niż zazwyczaj mamy przy tworzeniu interfejsu. Chciałbym jednak zwrócić uwagę, że w przypadku jednorazowych skryptów wydajność nie jest aż tak ważna (chyba, że to co robisz jest naprawdę obciążające). W moim przypadku działało to bardzo szybko. Powolna część nie polegała na wielokrotnym iterowaniu po tablicy elementów, ale na uruchamianiu poleceń.

Inni mówili, bym używał API od Node-a lub modułów open source z npm, aby ułatwić uruchamianie tych skryptów, ponieważ "prawdopodobnie byłoby to szybsze i działałoby na różnych platformach". Ponownie, najpewniej mają rację, ale w przypadku jednorazowych skryptów, które są "wystarczająco szybkie" te rzeczy nie mają znaczenia. Jest to klasyczny przykład nakładania nieistotnych ograniczeń na program, co skutkuje bardziej skomplikowanym rozwiązaniem.

W każdym razie, chciałem przyjrzeć się kwestii użycia .reduce() zamiast .map() lub .filter().

`.reduce()`

Oto jak wyglądałby ten sam kod z użyciem .reduce():

const commands = lines.reduce((accumulator, line) => {
  let file = line.trim()
  if (file) {
    const destFile = getDestFile(file)
    const destFileDir = path.dirname(destFile)
    accumulator.push(`mkdir -p "${destFileDir}" && mv "${file}" "${destFile}"`)
  }
  return accumulator
}, [])

Nie jestem jedną z tych osób, które uważają, że używanie .reduce() jest złe
(sprawdź ten wątek, po więcej ciekawych przykładów użycia .reduce()), ale myślę, że jestem w stanie rozpoznać, kiedy kod jest prostszy/bardziej skomplikowany i muszę przyznać, że przykład z użyciem chaining-u jest zdecydowanie prostszy.

Pętla

Szczerze, używam metod tablicowych tak długo, że potrzebuję chwili by napisać to z użyciem pętli. Jedną chwileczkę...

const commands = []
for (let index = 0; index < lines.length; index++) {
  const line = lines[index]
  const file = line.trim()
  if (file) {
    const destFile = getDestFile(file)
    const destFileDir = path.dirname(destFile)
    commands.push(`mkdir -p "${destFileDir}" && mv "${file}" "${destFile}"`)
  }
}

To też nie jest dużo prostsze.

EDIT: ALE CZEKAJ! Możemy to uprościć za pomocą for...of!

const commands = []
for (const line of lines) {
  const file = line.trim()
  if (!file) continue

  const destFile = getDestFile(file)
  const destFileDir = path.dirname(destFile)
  commands.push(`mkdir -p "${destFileDir}" && mv "${file}" "${destFile}"`)
}

Osobiście uważam, że nie jest to dużo lepsze niż tradycyjna pętla, ale sądzę, że jest całkiem proste. Niektórzy uważają pętle za zbyt "imperatywne", ale niekiedy są przydatne.

Podsumowanie

Często będę wybierać pomiędzy chaining-iem, a pętlą for...of. Jeśli pojawi się problem z wielokrotnym iterowaniem po tablicy to z pewnością zdecyduję się na for...of.

Osobiście nie używam często metody .reduce(), ale czasami ją wykorzystuję. Zdaję sobie sprawę, jak subiektywnie to brzmi, ale tak duża część programowania jest subiektywna 🤷‍♂️

Daj mi znać co o tym myślisz!

React Context - jak efektywnie go używać?

Bartosz Zagrodzki — Fri, 08 Oct 2021 14:37:48 +0000

Przetłumaczona wersja artykułu Kenta C. Doddsa

We wpisie o zarządzaniu stanem aplikacji w React wspominałem, jak używanie stanu lokalnego wraz z kontekstem może pomóc w zarządzaniu stanem dowolnej aplikacji. Pokazałem tam kilka przykładów do których chciałbym się teraz odnieść, by przedstawić jak efektywnie tworzyć konsumentów kontekstu, unikając problemów, a jednocześnie poprawiając czytelność kodu i ułatwiając jego utrzymanie dla Twoich aplikacji i/lub bibliotek.

Zapoznaj się z zarządzaniem stanu w React i postępuj zgodnie z radą, mówiącą, że nie powinieneś używać kontekstu do rozwiązania każdego problemu ze stanem w aplikacji. Ale kiedy już będziesz zmuszony po niego sięgnąć, mam nadzieję, że ten wpis pomoże ci się dowiedzieć jak skutecznie to zrobić. Pamiętaj, że kontekst NIE musi być globalny dla całej aplikacji, ale może być zastosowany do jednej jej części i możesz (a prawdopodobnie powinieneś) mieć wiele logicznie oddzielonych od siebie kontekstów.

Najpierw, stwórzmy plik src/count-context.js, a w nim kontekst:

import * as React from 'react'

const CountContext = React.createContext()

Po pierwsze, nie mam tutaj domyślnej wartości dla kontekstu. Jeśli chciałbym ją dodać musiałbym zrobić coś takiego: React.createContext({count: 0}). Zrobiłem to jednak celowo. Dodawanie wartości domyślnej jest użyteczne tylko w takim przypadku:

function CountDisplay() {
  const {count} = React.useContext(CountContext)
  return <div>{count}</div>
}

ReactDOM.render(<CountDisplay />, document.getElementById('⚛️'))

Ponieważ nie mamy wartości domyślnej, otrzymamy błąd w linii, gdzie destrukturyzujemy wartość zwracaną z useContext(). Dzieje się tak, gdyż nie możemy destrukturyzować undefined, a właśnie taką wartość domyślną ma nasz kontekst.

Nikt z nas nie lubi takich sytuacji, więc Twoją odruchową reakcją może być dodanie domyślnej wartości, aby uniknąć błędu. Jaki byłby jednak pożytek z kontekstu, gdyby nie wskazywał on na aktualny stan? Używając tylko domyślnych wartości, nie mógłby wiele zdziałać. W 99% przypadków, gdy będziesz tworzyć i używać kontekstu w swojej aplikacji, chciałbyś aby komponenty-konsumenci (korzystający z useContext()) były renderowane w ramach rodzica-dostawcy, który może zapewnić użyteczną wartość.

Istnieją sytuacje w których wartości domyślne są przydatne, lecz w większości przypadków tak nie jest.

Dokumentacja Reacta sugeruje, że podanie wartości domyślnej "przydaje się podczas testowania komponentów w izolacji, ponieważ nie ma konieczności opakowywania ich w sztucznych dostawców". Chociaż prawdą jest, że pozwala to zrobić, nie zgadzam się, że jest to lepsze od zapewniania komponentom niezbędnego kontekstu. Pamiętaj, że za każdym razem, gdy robisz w teście coś, czego nie ma w aplikacji, zmniejszasz pewność, jaką może dać Ci test. Istnieją powody, by tak robić, ale to nie jest jeden z nich.

Jeśli używasz TypeScript-u, brak wartości domyślnej może być naprawdę irytujący dla osób korzystających z React.useContext, ale pokażę ci, jak uniknąć tego problemu. Czytaj dalej!

Ok, kontynuujmy. Aby ten moduł kontekstu był w ogóle użyteczny, musimy użyć Provider-a i udostępnić komponent, który dostarcza wartość. Nasz komponent będzie używany w następujący sposób:

function App() {
  return (
    <CountProvider>
      <CountDisplay />
      <Counter />
    </CountProvider>
  )
}

ReactDOM.render(<App />, document.getElementById('⚛️'))

Stwórzmy więc komponent, którego można użyć w ten sposób:

import * as React from 'react'

const CountContext = React.createContext()

function countReducer(state, action) {
  switch (action.type) {
    case 'increment': {
      return {count: state.count + 1}
    }
    case 'decrement': {
      return {count: state.count - 1}
    }
    default: {
      throw new Error(`Unhandled action type: ${action.type}`)
    }
  }
}

function CountProvider({children}) {
  const [state, dispatch] = React.useReducer(countReducer, {count: 0})
  // NOTE: *możesz* potrzebować memoizacji tej wartości
  // Dowiedz się więcej: http://kcd.im/optimize-context
  const value = {state, dispatch}
  return <CountContext.Provider value={value}>{children}</CountContext.Provider>
}

export {CountProvider}

Spokojnie, to wymyślony przykład, który celowo jest tak zrobiony, by pokazać, jak wyglądałaby bardziej rzeczywista sytuacja. Nie oznacza to, że za każdym razem będzie to tak skomplikowane! Jeśli to pasuje do Twojego przypadku możesz użyć useState. Ponadto, niektóre komponenty-dostawcy będą tak proste i krótkie, a inne DUŻO bardziej zawiłe, zawierające wiele hooków.

Customowy hook konsumenta

Większość interfejsów API, które widziałem, wygląda mniej więcej tak:

import * as React from 'react'
import {SomethingContext} from 'some-context-package'

function YourComponent() {
  const something = React.useContext(SomethingContext)
}

Ale sądzę, że to zmarnowana szansa na zapewnienie lepszego user experience. Moim zdaniem powinno to być coś takiego:

import * as React from 'react'
import {useSomething} from 'some-context-package'

function YourComponent() {
  const something = useSomething()
}

Ma to tą zaletę, że możesz zrobić kilka rzeczy, które teraz pokażę w praktyce:

import * as React from 'react'

const CountContext = React.createContext()

function countReducer(state, action) {
  switch (action.type) {
    case 'increment': {
      return {count: state.count + 1}
    }
    case 'decrement': {
      return {count: state.count - 1}
    }
    default: {
      throw new Error(`Unhandled action type: ${action.type}`)
    }
  }
}

function CountProvider({children}) {
  const [state, dispatch] = React.useReducer(countReducer, {count: 0})
  // NOTE: *możesz* potrzebować memoizacji tej wartości
  // Dowiedz się więcej: http://kcd.im/optimize-context
  const value = {state, dispatch}
  return <CountContext.Provider value={value}>{children}</CountContext.Provider>
}

function useCount() {
  const context = React.useContext(CountContext)
  if (context === undefined) {
    throw new Error('useCount must be used within a CountProvider')
  }
  return context
}

export {CountProvider, useCount}

Najpierw, hook useCount używa React.useContext, by otrzymać wartość kontekstu od najbliższego CountProvider. Jeśli nie ma takiej wartości, zwróci błąd zawierający pomocną wiadomość, wskazując, że hook nie został wywołany w komponencie funkcyjnym wyrenderowanym pod CountProvider. Jest to z pewnością błąd,
dlatego zwrócenie odpowiedniego komunikatu może być cenne. #FailFast

Customowy komponent konsumenta

Jeśli używasz hooków, pomiń tę sekcję. Jednak, jeśli musisz mieć wsparcie dla Reacta w wersji < 16.8.0 lub myślisz, że kontekst musi zostać użyty z komponentami klasowymi, oto jak możesz to zrobić korzystając z render-props:

function CountConsumer({children}) {
  return (
    <CountContext.Consumer>
      {context => {
        if (context === undefined) {
          throw new Error('CountConsumer must be used within a CountProvider')
        }
        return children(context)
      }}
    </CountContext.Consumer>
  )
}

A oto jak można to wykorzystać w komponentach klasowych:

class CounterThing extends React.Component {
  render() {
    return (
      <CountConsumer>
        {({state, dispatch}) => (
          <div>
            <div>{state.count}</div>
            <button onClick={() => dispatch({type: 'decrement'})}>
              Decrement
            </button>
            <button onClick={() => dispatch({type: 'increment'})}>
              Increment
            </button>
          </div>
        )}
      </CountConsumer>
    )
  }
}

Używałem tego, zanim mieliśmy dostęp do hooków i działało sprawnie. Nie polecam jednak zawracania sobie tym głowy, jeśli możesz używać hooków. Hooki są znacznie lepsze.

TypeScript

Obiecałem, że pokażę, jak ustrzec się błędów związanych z pomijaniem wartości domyślnej, używając TypeScript-u. Zgadnij co! Robiąc, to o czym wspominałem, od razu unikasz problemu! Właściwie to wcale nie jest problem. Rzuć okiem na to:

import * as React from 'react'

type Action = {type: 'increment'} | {type: 'decrement'}
type Dispatch = (action: Action) => void
type State = {count: number}
type CountProviderProps = {children: React.ReactNode}

const CountStateContext = React.createContext<
  {state: State; dispatch: Dispatch} | undefined
>(undefined)

function countReducer(state: State, action: Action) {
  switch (action.type) {
    case 'increment': {
      return {count: state.count + 1}
    }
    default: {
      throw new Error(`Unhandled action type: ${action.type}`)
    }
  }
}

function CountProvider({children}: CountProviderProps) {
  const [state, dispatch] = React.useReducer(countReducer, {count: 0})
  // NOTE: *możesz* potrzebować memoizacji tej wartości
  // Dowiedz się więcej: http://kcd.im/optimize-context
  const value = {state, dispatch}
  return (
    <CountStateContext.Provider value={value}>
      {children}
    </CountStateContext.Provider>
  )
}

function useCount() {
  const context = React.useContext(CountStateContext)
  if (context === undefined) {
    throw new Error('useCount must be used within a CountProvider')
  }
  return context
}

export {CountProvider, useCount}

Dzięki temu każdy może używać hooka useCount bez konieczności sprawdzania wartości, ponieważ robimy to za niego!

Działający przykład - CodeSandbox

Co z literówkami w `dispatch`?

Jeśli chcesz używać kreatorów akcji, ok, ja jednak nigdy za tym nie przepadałem. Zawsze uważałem, że są one niepotrzebną abstrakcją. Używając TypeScript-u i mając dobrze otypowane akcje, najprawdopodobniej ich nie potrzebujesz. Dzięki temu uzyskujesz autouzupełnianie składni!

Polecam używać dispatch w ten sposób, dzięki temu jest on stabilny przez cały czas życia komponentu, który go utworzył, więc nie musisz martwić się o przekazywanie go jako zależności do useEffect.

Jeśli nie typujesz swojego kodu JavaScript (prawdopodobnie powinieneś to zmienić) wtedy zwracany błąd okaże się bezpiecznym rozwiązaniem. Przejdźmy do następnej sekcji, powinna ci pomóc.

Co z asynchronicznością?

Dobre pytanie. Co się stanie, jeśli będziesz potrzebował wykonywać asynchroniczne żądanie i zmienić kilka rzeczy podczas jego trwania? Jasne, że możesz to zrobić bezpośrednio w komponencie, ale ręczne ustawianie tego w każdej sytuacji byłoby dość denerwujące.

Sugeruję użycie funkcji pomocniczej, która przyjmuje jako argumenty dispatch oraz inne potrzebne dane i będzie odpowiedzialna za obsługę tego wszystkiego. Tutaj przykład z mojego kursu o zaawansowanych wzorcach w React:

async function updateUser(dispatch, user, updates) {
  dispatch({type: 'start update', updates})
  try {
    const updatedUser = await userClient.updateUser(user, updates)
    dispatch({type: 'finish update', updatedUser})
  } catch (error) {
    dispatch({type: 'fail update', error})
  }
}

export {UserProvider, useUser, updateUser}

Następnie możesz tego użyć w ten sposób:

import {useUser, updateUser} from './user-context'

function UserSettings() {
  const [{user, status, error}, userDispatch] = useUser()

  function handleSubmit(event) {
    event.preventDefault()
    updateUser(userDispatch, user, formState)
  }

  // more code...
}

Jestem zadowolony z tego wzorca, więc jeśli chciałbyś bym nauczył go w Twojej firmie daj mi znać (lub dopisz się do listy oczekujących na kolejne warsztaty)!

Podsumowanie

Tak wygląda finalny kod:

import * as React from 'react'

const CountContext = React.createContext()

function countReducer(state, action) {
  switch (action.type) {
    case 'increment': {
      return {count: state.count + 1}
    }
    case 'decrement': {
      return {count: state.count - 1}
    }
    default: {
      throw new Error(`Unhandled action type: ${action.type}`)
    }
  }
}

function CountProvider({children}) {
  const [state, dispatch] = React.useReducer(countReducer, {count: 0})
  // NOTE: *możesz* potrzebować memoizacji tej wartości
  // Dowiedz się więcej: http://kcd.im/optimize-context
  const value = {state, dispatch}
  return <CountContext.Provider value={value}>{children}</CountContext.Provider>
}

function useCount() {
  const context = React.useContext(CountContext)
  if (context === undefined) {
    throw new Error('useCount must be used within a CountProvider')
  }
  return context
}

export {CountProvider, useCount}

A tutaj działający CodeSandbox

Zauważ, że celowo nie eksportuję tutaj CountContext. Używam tylko jednego sposobu zarówno by ustawić, jak i wyciągnąć wartości. Dzięki temu mam pewność, że inni korzystają z tych wartości w bezpieczny sposób.

Mam nadzieję, że ten artykuł okazał się dla Ciebie pomocny! Pamiętaj:

Nie powinieneś używać kontekstu, by rozwiązać każdy problem ze stanem.
Kontekst nie musi być globalny dla całej aplikacji, a tylko dla jej części.
Możesz (i prawdopodobnie powinieneś) mieć kilka, oddzielonych od siebie logicznie kontekstów.

Powodzenia!

DEV Community: Bartosz Zagrodzki

Jak zoptymalizować React Context?

Rozdzielenie stanu i dispatch bywa irytujące

Testy statyczne vs jednostkowe vs E2E w aplikacjach frontendowych

Typy testów

End to End

Integracyjne

Jednostkowe

Statyczne

Dlaczego testujemy ponownie?

Porozmawiajmy o kompromisach

Koszt: ￠heap ➡ 💰🤑💰

Prędkość: 🏎💨 ➡ 🐢\

Pewność: Proste sprawy 👌 ➡ Duże problemy 😖

Wnioski

pętla for vs chaining vs .reduce()

.reduce()

Pętla

Podsumowanie

React Context - jak efektywnie go używać?

Customowy hook konsumenta

Customowy komponent konsumenta

TypeScript

Co z literówkami w dispatch?

Co z asynchronicznością?

Podsumowanie

Rozdzielenie stanu i `dispatch` bywa irytujące

`.reduce()`

Co z literówkami w `dispatch`?