React — pytania rekrutacyjne i zadanie z formularzem zamówienia

Formularz zamówienia może wyglądać poprawnie, a mimo to pokazać błąd poprzedniego zamówienia, przypisać ilość do niewłaściwej pozycji i zastąpić nową ofertę dostawy starszą odpowiedzią. W zadaniu rekrutacyjnym ustal, do którego zamówienia, wiersza lub wyboru dostawy należy stan. Dopiero potem wybieraj Hooki i poprawki.

Prześledź trzy odtwarzalne błędy lokalnego komponentu i uzasadnij każdą poprawkę. Do dalszej praktyki użyj Build a React Typeahead with Async Suggestions and Keyboard Navigation: podobnie jak przy ofercie dostawy, trzeba odróżnić aktualną odpowiedź od wyniku wcześniejszego wyboru.

Granica dowodów: oficjalne materiały React opisują zachowanie stanu, kluczy i Effectów. Formularz, dane oraz scenariusze są autorskie. Wykonano 18 asercji rzeczywistych interakcji DOM w React 19.3.0 i Chrome 154. Oferty są kontrolowanymi obietnicami lokalnymi; nie wysłano zamówienia ani żądania do serwera. Nie wykorzystujemy relacji kandydatów do twierdzeń o procesie konkretnej firmy.

Ustal trzy odrębne granice stanu

W ćwiczeniu zamówienie A i zamówienie B są osobnymi formularzami. Przełączenie ma usunąć lokalny szkic kodu pocztowego oraz jego komunikat walidacyjny. Pozycje A i B mają natomiast zachować własną ilość po odwróceniu kolejności. Oferta dostawy musi odpowiadać aktualnemu wyborowi: odbiór albo kurier. Te wymagania wskazują trzy różne tożsamości.

Nie zakładaj, że wszystko należy do jednego dużego obiektu formState. Błąd kodu pocztowego dotyczy konkretnego formularza, ilość dotyczy pozycji, a wynik oferty dotyczy wyboru dostawy. Wspólny komponent może je wyświetlać, ale nie znaczy to, że wszystkie dane powinny być resetowane tym samym zdarzeniem. Narysuj granice przed zmianą implementacji.

Laboratorium celowo rozdziela trzy panele. Pozycje służą do demonstracji kluczy i nie wyznaczają wartości koszyka. Dla porównania ofert przyjmujemy stałą bazę 2000 groszy; kurier kosztuje 500, a odbiór zero. To mały model zachowania UI, a nie kompletny sklep z obliczaniem cen, podatków i dostępności produktów.

Błąd 1: komunikat A pozostaje w formularzu B

Wybierz zamówienie A, wpisz 12 w pole kodu pocztowego i uruchom sprawdzenie. Uproszczony walidator wymaga pięciu znaków, więc pokaże komunikat. Następnie wybierz zamówienie B. W błędnym wariancie zostają zarówno tekst 12, jak i błąd A, choć legenda pokazuje już B.

Powód: renderujesz ten sam komponent na tej samej pozycji, zmieniając jedynie prop order. Jego useState('') nie jest ponownie inicjalizowane przy każdej zmianie propa. Oficjalny materiał Preserving and Resetting State opisuje powiązanie stanu z pozycją, typem i kluczem komponentu. Zmiana danych wejściowych nie oznacza automatycznie nowej tożsamości.

Dla wybranego kontraktu poprawka ustanawia granicę formularza:

<OrderForm key={order.id} order={order} />

W laboratorium identyfikator jest bezpośrednio tekstem A lub B, więc zapis ma postać <Form key={order} order={order} />. Po zmianie klucza nowy formularz zaczyna z pustym polem i bez błędu. Nie przepisuj wariantu z order.id, jeśli twój order jest tekstem; dopasuj kod do modelu danych.

Reset jest decyzją produktu, nie uniwersalną poradą

Zmiana klucza usuwa cały lokalny stan pod tą granicą. Jeśli użytkownik powinien wrócić do A i odzyskać szkic, nasza poprawka nie spełni wymagania. Trzeba wówczas przechowywać szkice według identyfikatora zamówienia albo wybrać inną, jawną politykę. Jeśli powrót do A ma przywrócić szkic, reset całego formularza usunie dane, które trzeba zachować.

W tym ćwiczeniu reset jest zamierzony: przełączenie otwiera niezależny formularz. Test sprawdza zarówno komunikat, jak i zawartość pola, ponieważ usunięcie samego błędu nie wystarcza. Po poprawce B ma pusty kod oraz Brak błędu. To dowód spełnienia dwóch konkretnych warunków, nie walidacji rzeczywistego kodu pocztowego dowolnego kraju.

Nie dodawaj Effectu, który przy zmianie order ręcznie czyści dziesięć pól, zanim określisz granicę stanu. Taki kod łatwo rozjeżdża się z kolejnymi polami i tworzy dodatkowy etap aktualizacji. Klucz jest odpowiedni dla pełnego resetu tej tożsamości; selektywny reset albo zachowanie szkiców wymaga innego kontraktu i osobnych testów.

Błąd 2: ilość przechodzi do innego wiersza

Na początku pozycja A ma ilość jeden, a B dwa. Zmień A na dziewięć i odwróć kolejność pozycji. Gdy kluczem jest indeks tablicy, widoczna pozycja B dostaje dziewięć, a A dwa. Lokalny stan wiersza został przypisany pozycji w drzewie, która po zmianie reprezentuje inny produkt.

// Błędny wariant dla listy zmieniającej kolejność
rows.map((row, index) => <Row key={index} row={row} />)

// Tożsamość pozycji pozostaje taka sama po zmianie kolejności
rows.map(row => <Row key={row.id} row={row} />)

W zapisanym teście poprawionego wariantu A zachowuje 9, a B 2 po odwróceniu kolejności. Identyfikator musi być stabilny dla danego elementu i unikalny wśród jego rodzeństwa. Losowanie klucza przy renderowaniu powodowałoby kolejne utraty stanu; nazwa produktu również nie jest bezpieczna, jeśli może się zmieniać albo powtarzać. Tożsamość powinna wynikać z modelu pozycji.

Zauważ, że samo odwrócenie tablicy nie zmieniło obiektów na inne produkty. W laboratorium tworzymy nową tablicę przez [...current].reverse(), zachowując dane wejściowe stanu. Błąd dotyczy sposobu powiązania komponentów z elementami. Nie diagnozuj go jako „React źle sortuje”, gdy przyczyną jest klucz wybrany przez aplikację.

Kto przechowuje ilość i kiedy ją synchronizować

Nasz Row inicjalizuje lokalną ilość z row.qty, a potem pozwala ją edytować. To celowy wybór do pokazania skutku kluczy. Jeżeli rodzic później zmieni row.qty dla tego samego identyfikatora, lokalny stan nie zostanie samoczynnie zastąpiony. Poprawny klucz nie rozstrzyga synchronizacji dwóch źródeł danych.

W pełnym formularzu możesz trzymać ilości w rodzicu i przekazywać kontrolowaną wartość wraz z callbackiem zmiany. Możesz też utrzymywać lokalny szkic z jawnym zatwierdzeniem. Najpierw określ, czy aktualizacja serwera powinna nadpisać rozpoczętą edycję. Dodanie Effectu kopiującego każdy nowy prop do stanu może zniszczyć wpis użytkownika i ukryć konflikt.

Oficjalna dokumentacja input opisuje wymagania pól kontrolowanych. W demonstracji value pozostaje tekstem, a onChange aktualizuje stan. Przechowanie '' ma sens podczas edycji; nie zmieniaj pustego pola od razu w zero tylko po to, aby typ wyglądał wygodniej. Interpretacja i walidacja ilości są kolejnym wymaganiem, którego ten panel nie implementuje.

Błąd 3: stara oferta nadpisuje nowy wybór

Początkowo wybrany jest odbiór. Przełącz dostawę na kuriera, ale nie kończ jeszcze wcześniejszej obietnicy. Najpierw zakończ ofertę kuriera z kosztem 500 groszy, następnie spóźnioną ofertę odbioru z kosztem zero. Błędny wariant pokaże odbiór, choć użytkownik nadal wybrał kuriera.

To wyścig wyników względem aktualnego wyboru. Kolejność uruchomienia operacji nie gwarantuje kolejności ich zakończenia. Test kontroluje tę kolejność przyciskami, zamiast liczyć na przypadkowe opóźnienie sieci. Dzięki temu błąd da się odtworzyć za każdym razem i porównać z poprawionym wariantem przy tych samych danych.

Oficjalna dokumentacja useEffect pokazuje sprzątanie Effectu oraz ignorowanie nieaktualnych odpowiedzi. Dla naszego źródła obietnic wariant naprawiony ma taki sens:

useEffect(() => {
  let ignore = false;
  api.get(shipping).then(result => {
    if (!ignore) setQuote(result);
  });
  return () => { ignore = true; };
}, [shipping, api]);

Każde uruchomienie ma własne ignore. Przy zmianie dostawy sprzątanie oznacza poprzednią operację jako nieaktualną. Stabilne api powstaje raz dla instancji laboratorium; nie tworzymy nowego obiektu w każdym renderze. W produkcyjnej integracji trzeba również rozważyć odrzucenie, anulowanie i politykę pamięci podręcznej.

Ignorowanie wyniku nie anuluje operacji

Flaga blokuje zapis starego wyniku do stanu. Nie zatrzymuje obietnicy i nie cofa efektów po stronie serwera. Nasze lokalne źródło nadal kończy wcześniejszą ofertę; jej wynik po prostu nie zmienia aktualnego widoku. To wystarcza do wymaganego zachowania demonstracji, ale nie jest gwarancją ograniczenia transferu lub liczby operacji.

Wariant poprawiony sprawdza również tożsamość przy wyświetlaniu: oferta jest widoczna tylko wtedy, gdy jej id odpowiada shipping. Dzięki temu poprzednia oferta nie wygląda jak aktualna podczas oczekiwania na nową. Sprzątanie chroni przed późniejszym nadpisaniem, a kontrola tożsamości chroni znaczenie już przechowywanego wyniku. Kontrola identyfikatora ukrywa starą ofertę podczas oczekiwania, a sprzątanie odrzuca jej późniejsze zakończenie.

Jeśli źródło danych może zwrócić kilka żądań dla tej samej dostawy, sam identyfikator sposobu dostawy nie musi wystarczyć. Wtedy potrzebujesz tożsamości żądania lub dodatkowego numeru wersji. Nasz test obejmuje przejście odbiór → kurier i odwrócone zakończenie tych dwóch operacji. Nie rozszerzaj jego wyniku na wszystkie możliwe sekwencje odświeżania.

Suma jest wynikiem danych, nie osobnym Effectem

Dla stałej bazy 2000 groszy i bieżącej oferty 500 wynik to 2500. Nie potrzebujemy osobnego stanu total, który Effect aktualizuje po zmianie quote. Wystarczy obliczenie podczas renderowania, gdy oferta odpowiada wyborowi. Jeśli oferta jest nieaktualna albo jej brakuje, pokaż oczekiwanie, zamiast podawać sumę jako ostateczną.

Oficjalny materiał You Might Not Need an Effect zaleca rozróżnienie obliczeń wynikających z danych od synchronizacji z zewnętrznym systemem. W naszym przypadku pobranie oferty wymaga synchronizacji, natomiast dodanie dwóch kwot jej nie wymaga. Sprawdzenie formularza po kliknięciu pozostaje w obsłudze zdarzenia użytkownika.

Dla dodania 2000 i 500 groszy dodatkowe useMemo nie pomaga wyjaśnić poprawności; nie zmierzono tu przyspieszenia. Celem tej zmiany jest spójność źródeł danych: nie przechowujesz kopii sumy, którą można zapomnieć zaktualizować. W dużym koszyku najpierw ustal poprawność, potem zmierz rzeczywisty koszt obliczenia i dopiero oceniaj potrzebę optymalizacji.

Macierz akceptacji po trzech sekwencjach

Tabela zestawia dokładne wyniki zaobserwowane w obu wariantach. Ilości są tekstem pól, a kwoty zapisano w groszach. Każdy scenariusz rozpoczyna się od resetu odpowiedniego wariantu; nie korzysta z resztek stanu wcześniejszej próby.

Osiemnaście asercji obejmuje stan początkowy i utworzenie błędu, oba pola po przełączeniu zamówienia, dwie ilości po odwróceniu, ofertę kuriera przed spóźnionym wynikiem, ofertę po nim oraz końcową sumę. Dziewięć sprawdzeń wykonano dla każdego wariantu. PASS raportu oznacza zgodność z macierzą: błędny wariant odtwarza defekt, a poprawiony spełnia wskazane warunki.

Nie są to testy kompletności zamówienia, walidacji krajowego kodu pocztowego, czytnika ekranu ani wydajności. Laboratorium działa jako deweloperski build bez opakowania StrictMode; nie wywodzimy z liczby wywołań gwarancji dla innych konfiguracji. Źródło komponentów i raport interakcji pozwalają dokładnie ustalić zakres dowodu.

Jak rozszerzyć rozmowę bez rozszerzania dowodu

Jeżeli prowadzący doda sekwencję odbiór → kurier → odbiór, zapisz trzy osobne operacje, nawet gdy pierwsza i trzecia mają ten sam sposób dostawy. Sprawdzenie quote.id === shipping porównuje kategorię, a nie konkretną generację żądania. Zapytaj, czy druga oferta odbioru może mieć inną cenę lub termin. Dopiero wtedy określ potrzebną tożsamość odpowiedzi. Tej trzyetapowej sekwencji nie zaliczamy do wykonanych osiemnastu asercji.

Jeżeli oferta zostanie odrzucona, widok potrzebuje rozróżnienia oczekiwania, błędu i gotowego wyniku. Nie zamieniaj błędu na koszt zero: wyglądałby jak potwierdzony bezpłatny odbiór. Nasze źródło demonstracyjne zawsze kończy się sukcesem, więc nie dostarcza dowodu obsługi odrzucenia. Dobrym następnym testem byłoby odrzucenie aktualnej operacji przy jednoczesnym sukcesie starszej i sprawdzenie, który komunikat pozostaje widoczny.

Przy zmianie wymagań formularza zapytaj także o zatwierdzenie szkicu. Panel kodu pocztowego ma przycisk sprawdzenia, ale nie implementuje wysyłania, obsługi Enter ani przenoszenia fokusu do błędu. Samo istnienie kontrolowanego pola nie potwierdza dostępności kompletnej ścieżki. Możesz wskazać te zadania jako rozszerzenie, zamiast opisywać nieprzetestowane zachowanie jako gotowe.

Na koniec oddziel poprawność UI od uprawnień i ceny zamówienia. Lokalny widok może pokazać 2500 groszy, lecz serwer powinien niezależnie ustalić dopuszczalną operację według swojego kontraktu. W tym laboratorium takiego serwera nie ma. Uczciwa odpowiedź kończy się wskazaniem tej granicy: udowodniliśmy przynależność stanu i wyniku do interakcji, a nie poprawność całej transakcji handlowej.

Pięć pytań PracHub związanych z tym formularzem

Zweryfikowane strony mają angielskie tytuły. Nie przedstawiamy ich jako osobnej polskiej kolekcji zamówień. Każda rozwija konkretny problem z tego ćwiczenia: właściciela stanu, wyniki asynchroniczne, walidację lub tożsamość wierszy.

Przećwicz Build a React Typeahead with Async Suggestions and Keyboard Navigation, odwracając kolejność zakończenia odpowiedzi. Najpierw opisz, które dane mogą zmienić widok; potem pokaż asercję, że stary wynik nie zastąpi aktualnego. Taki dowód jest bardziej użyteczny niż wymienienie wszystkich Hooków bez związku z interakcją.

Sources and Further Reading

• React: Preserving and Resetting State
• React: useEffect
• React DOM: input
• React: You Might Not Need an Effect