Dowiedz się, jak React Jordana Walke wprowadził wielokrotnego użytku komponenty, deklaratywne widoki i renderowanie napędzane stanem — przekształcając współczesną architekturę frontendów.
Jordan Walke to inżynier oprogramowania najbardziej znany z stworzenia Reacta podczas pracy w Facebooku. Przed Reactem frontend często opierał się na stronach, szablonach i rosnącej stercie „kodów łączących”, które próbowały utrzymać HTML, CSS i JavaScript w zgodzie. Kluczowy pomysł Walke’a polegał na odwróceniu modelu: zamiast traktować UI jak dokumenty, które łatamy w czasie, traktuj je jako drzewo małych, wielokrotnego użytku komponentów, które komponujesz w większe funkcje.
To nie była tylko nowa biblioteka — to nowy sposób myślenia o pracy nad interfejsem. Komponent łączy fragment interfejsu z logiką i stanem, których potrzebuje, a następnie udostępnia czysty interfejs (props) reszcie aplikacji. Dzięki temu praca nad UI przypomina bardziej budowanie z klocków Lego niż edytowanie jednej kruchej strony.
React miał znaczenie, bo pomógł zespołom:
Przejdziemy przez praktyczne idee, które uczyniły React wpływowym:
Nie musisz być ekspertem od frameworków, aby to zrozumieć. Celem jest jasne przedstawienie modelu myślenia — żebyś potrafił rozpoznać dobre wzorce Reacta, unikać powszechnych nieporozumień i stosować te same zasady także poza Reactem.
Przed Reactem wiele zespołów budowało bogate interfejsy, zszywając szablony, manipulacje DOM w stylu jQuery i rosnącą stertę reguł „gdy X się zdarzy, uaktualnij Y”. Działało — dopóki UI nie zaczęło być zbyt złożone.
Częstym wzorcem było: pobierz dane, wygeneruj HTML, a potem podłącz handler-y zdarzeń, które mutują DOM bezpośrednio. W momencie zmiany stanu (nowy element, błąd walidacji, przełączenie) ktoś musiał pamiętać o każdej zależnej części.
To prowadziło do błędów, takich jak:
W miarę rozwoju ekranów te same reguły biznesowe rozpływały się po wielu handlerach: „wyłącz przycisk, jeśli pole jest puste”, „wyróżnij nieprzeczytane”, „pokaż stan pusty, gdy brak wyników”. Gdy wymagania się zmieniały, trzeba było przeszukiwać niepowiązane pliki, żeby zaktualizować każdą kopię.
Dane można zwykle wymodelować kilkoma klarownymi strukturami: lista postów, obiekt użytkownika, zestaw filtrów. UI dodaje jednak kombinacje: ładowanie vs załadowane, błąd vs sukces, przeczytane vs nieprzeczytane, edycja vs podgląd, filtrowane vs niefiltrowane — często wszystko naraz.
Wyobraź sobie kanał informacyjny:
Bez przewidywalnej reguły „UI jest funkcją stanu” kończysz koordynując wiele edycji DOM, które mogą sobie wzajemnie przeszkadzać. Celem Reacta było uczynienie aktualizacji niezawodnymi: zmień dane/stan, a UI za każdym razem wyrenderuje się tak, żeby do nich pasować.
Komponent to mały fragment interfejsu, który można nazwać, ponownie użyć i o którym można myśleć niezależnie. Prosto: komponent przyjmuje wejścia, i zwraca to, jak powinien wyglądać interfejs dla tych wejść.
To ramowanie „wejścia → wyjście” jest sednem modelu komponentów. Zamiast traktować ekran jako jeden wielki szablon, dzielisz go na celowe klocki — przyciski, karty, menu, formularze, a nawet całe sekcje — i składasz je razem.
W React najczęstsze wejścia to props (właściwości). Props to wartości przekazywane do komponentu, które go konfigurują: tekst, liczby, flagi, handler-y zdarzeń, a nawet inny UI.
Wynikiem jest UI, które komponent renderuje. Jeśli propsy się zmienią, komponent może wygenerować inny wynik — bez ręcznego tropienia, gdzie zaktualizować DOM.
Na przykład komponent Button może otrzymać propsy takie jak label, disabled i onClick. UserCard może otrzymać name, avatarUrl i status. Interfejs komponentu (jego propsy) czytasz podobnie jak spec produktu: „Czego ten UI potrzebuje, żeby poprawnie się wyrenderować?”
Podział UI na komponenty szybko się opłaca:
Modal, Input czy Dropdown może pojawić się na wielu stronach.To duże odejście od kopiowania i poprawiania markupu na stronę. Komponenty sprawiają, że duplikacja staje się zbędna — a z czasem nieakceptowalna.
React zachęca do projektowania UI tak, jak projektujesz system: jako części kompozycyjne. „Strona realizacji zamówienia” staje się drzewem komponentów — CheckoutPage zawiera OrderSummary, ShippingForm i PaymentMethod. Każda część ma jasne wejścia i odpowiedzialność.
To przejście — myślenie najpierw w komponentach — jest głównym powodem, dla którego React zmienił architekturę frontendu. Dał zespołom wspólną jednostkę projektowania i rozwoju: komponent.
Największa mentalna zmiana Reacta to deklaratywny UI: opisujesz, jak interfejs ma wyglądać dla danego stanu, a React zajmuje się aktualizacją strony, gdy ten stan się zmienia.
Zamiast ręcznie znajdować elementy, edytować tekst, przełączać klasy i utrzymywać DOM w zgodzie, skupiasz się na „kształcie” UI. Gdy dane się zmieniają, UI jest opisywane na nowo, a React znajduje minimalny zestaw zmian potrzebnych do zastosowania.
JSX to wygodny sposób pisania struktury komponentu używając składni przypominającej HTML wewnątrz JavaScriptu. To nie jest nowy język szablonów, którego musisz uczyć się od zera; to skrót oznaczający „ten komponent renderuje to drzewo elementów”.
Kluczowa korzyść polega na tym, że markup i logika decydująca o tym, co pokazać, żyją razem, co ułatwia zrozumienie komponentów w izolacji.
Kod imperatywny skupia się na tym, jak zaktualizować UI krok po kroku:
// Imperatywnie: ręczne utrzymywanie zgodności DOM
function setLoggedIn(isLoggedIn) {
const el = document.querySelector('#status');
el.textContent = isLoggedIn ? 'Welcome back' : 'Please sign in';
el.classList.toggle('ok', isLoggedIn);
el.classList.toggle('warn', !isLoggedIn);
}
Kod deklaratywny opisuje jaki interfejs powinien być dla bieżącego stanu:
function Status({ isLoggedIn }) {
return (
<p className={isLoggedIn ? 'ok' : 'warn'}>
{isLoggedIn ? 'Welcome back' : 'Please sign in'}
</p>
);
}
Ponieważ renderowanie jest wyrażone jako czysty opis, komponenty są czytelniejsze, łatwiejsze do przeglądu i prostsze do refaktoryzacji. Projektanci, inżynierowie zorientowani na produkt i nowi członkowie zespołu często potrafią zrozumieć JSX bez przeszukiwania handlerów zdarzeń i mutacji DOM.
Ta klarowność poprawia współpracę: decyzje UI są widoczne w jednym miejscu, a zmiany rzadziej powodują ukryte efekty uboczne w innych częściach interfejsu.
„Stan” to po prostu dane, które mogą się zmieniać w czasie, gdy użytkownik wchodzi w interakcję z UI. To może być aktualny tekst w polu wyszukiwania, czy menu jest otwarte, elementy w koszyku lub wynik zapytania sieciowego. Jeśli to się może zmienić i ekran powinien to odzwierciedlić, to jest to stan.
Kluczowy ruch Reacta polega na traktowaniu renderowania jako konsekwencji stanu, a nie sekwencji ręcznych kroków DOM. Opisujesz, jak UI ma wyglądać dla danego stanu. Gdy stan się zaktualizuje, React ponownie renderuje odpowiednie części.
To podejście różni się od „znajdź element, zaktualizuj jego tekst, przełącz tę klasę”. Zamiast tego aktualizujesz stan, a UI naturalnie się odświeża, bo jest z niego wyprowadzony.
Jednokierunkowy przepływ danych oznacza, że dane poruszają się w jednym kierunku:
To ogranicza niespodzianki, bo możesz śledzić ścieżkę aktualizacji: zdarzenie się dzieje, stan zmienia się w jednym miejscu, a UI się ponownie renderuje z tego nowego stanu. Jest mniej pytania „kto zmienił tę wartość?”.
function Counter() {
const [count, setCount] = React.useState(0);
return (
<div>
<p>Count: {count}</p>
<button onClick={() => setCount(count + 1)}>Add</button>
</div>
);
}
Tu count to stan. Kliknięcie przycisku aktualizuje stan przez setCount. React potem ponownie renderuje i paragraf pokazuje nową liczbę. Nigdy nie „edytujesz DOM-u” bezpośrednio.
Ten sam wzorzec skaluje się do filtrowania list (stan = tekst filtra, UI = przefiltrowane elementy) czy walidacji formularzy (stan = wartości pól i błędy, UI = komunikaty). Dane zmieniają się najpierw; widok jest tylko wynikiem.
Kluczowa idea Reacta to nie „szybsze przerysowywanie strony”. To: traktuj UI jako wynik stanu, i gdy stan się zmienia, porównaj, czego chcesz teraz, z tym, co miałeś wcześniej — a potem aktualizuj tylko to, co faktycznie się zmieniło.
Gdy stan lub propsy komponentu się zmieniają, React wywołuje twoje komponenty ponownie, żeby stworzyć nowy opis UI. Pomyśl o tym jak o dwóch migawkach:
Zamiast czyścić DOM i budować go od zera, React stara się obliczyć najmniejszy zestaw operacji DOM potrzebny do przejścia z A do B.
„Wirtualny DOM” to po prostu pamięciowa reprezentacja UI w React — lekka struktura drzewa elementów (i wyników komponentów), która opisuje, co powinno się znaleźć na ekranie. To nie drugi przeglądarek ani szybszy DOM; to struktura danych, którą React może efektywnie porównywać.
Rekonsylacja to proces ustalania, co się zmieniło między poprzednim drzewem wirtualnym a nowym. React używa heurystyk, by robić to szybko, na przykład:
<div> nie jest <span>)key) pomagają zidentyfikować elementy na liście, żeby React mógł dopasować „ten sam element” między renderamiKiedy React wie, co się zmieniło, stosuje celowane aktualizacje do rzeczywistego DOM-u.
To nie jest magia. Wydajność zależy od wzorców: stabilne klucze, unikanie niepotrzebnych ponownych renderów, trzymanie pracy komponentu małej i nieprzeprowadzanie drogich obliczeń podczas renderu. React może zmniejszyć drgania DOM, ale to struktura komponentów i przepływ danych wciąż decydują o płynności działania aplikacji.
Największy trik skalowania Reacta to nie jakaś flaga czy rozszerzenie — to kompozycja: budowanie ekranów przez zagnieżdżanie komponentów, przekazywanie danych przez props i używanie children, by komponent mógł „owijać” inny UI.
Gdy zespoły korzystają z kompozycji, przestają myśleć w kategoriach jednorazowych stron i zaczynają myśleć w kategoriach małych, niezawodnych części, które można przearanżować bez przepisywania wszystkiego.
childrenZagnieżdżanie odzwierciedla wizualną strukturę UI: strona zawiera sekcje, sekcje zawierają karty, karty zawierają przyciski. Props to pokrętła konfiguracji (tekst, stany, callbacki). children pozwala tworzyć komponenty, które definiują strukturę, jednocześnie pozwalając wywołującemu zdecydować, co w nich umieścić.
Dobry model myślowy: props konfigurują, children wypełniają, zagnieżdżanie składa.
Komponenty layoutowe definiują strukturę i odstępy bez posiadania logiki biznesowej. Przykłady: Page, SidebarLayout, Stack, Modal. Często polegają na children, więc ten sam layout może owinąć wiele różnych ekranów.
Wielokrotnego użytku pola formularzy standaryzują zachowanie i styl: TextField, Select, DatePicker. Zamiast kopiować etykiety, stany błędów i komunikaty walidacyjne, centralizujesz te decyzje i wystawiasz prosty API props.
Listy i komponenty elementów utrzymują powtarzalny UI przewidywalnym. Częstym podziałem jest ItemList (pobieranie, paginacja, stany puste) oraz ItemRow (jak wygląda pojedynczy element). Ułatwia to zmianę renderowania bez łamania obsługi danych.
Hooki to współczesny sposób ponownego używania zachowań z stanem (np. przełączniki, stan formularza, pobieranie danych) w różnych komponentach, bez narzucania im tej samej formy UI. To rozdzielenie pomaga zespołom ewoluować wygląd, zachowując spójną logikę.
Kompozycja to sposób, w jaki systemy projektowe pozostają spójne: komponenty stają się „zatwierdzonymi” blokami, a layouty definiują zasady odstępów i hierarchii. Gdy system się aktualizuje — kolory, typografia, stany interakcji — produkty dziedziczą ulepszenia przy minimalnych ręcznych zmianach.
Stan to po prostu „dane, które się zmieniają”. W React ważne jest, gdzie ten stan się znajduje.
Lokalny stan należy do jednego komponentu (lub małego widżetu) i nie musi być odczytywany gdzie indziej. Myśl: czy dropdown jest otwarty, bieżąca wartość inputu, która karta jest wybrana.
Trzymanie stanu lokalnego zmniejsza konieczność koordynacji i ułatwia ponowne użycie komponentu. Dobre reguły: jeśli tylko jeden komponent się o to troszczy, nie eksponuj tego na cały app.
Współdzielony stan to dane, które muszą być zgodne w wielu częściach UI. Typowe przykłady:
Gdy kilka komponentów potrzebuje tego samego źródła prawdy, duplikowanie stanu prowadzi do rozbieżności („nagłówek mówi 3 elementy, strona koszyka mówi 2”).
Podnieś stan wyżej: przenieś stan do najbliższego wspólnego rodzica i przekaż go w dół przez props. To często najprostsza opcja i utrzymuje przepływ danych jawny.
Context: przydatny, gdy wiele komponentów potrzebuje tej samej wartości bez „przekłuwania props” (prop drilling), np. motyw czy auth. Context najlepiej do względnie stabilnych, globalnych spraw.
Zewnętrzne store'y: gdy stan staje się złożony (częste aktualizacje, pochodne dane, workflowy obejmujące wiele stron), dedykowany store centralizuje logikę i aktualizacje.
Jednokierunkowy przepływ danych Reacta jest najsilniejszy, gdy dla każdego kawałka stanu jest jasny właściciel. Dąż do jednego źródła prawdy tam, gdzie to praktyczne, i wyprowadzaj resztę (liczniki, sumy, przefiltrowane listy) z tego stanu zamiast przechowywać duplikaty.
Największym codziennym zyskiem Reacta nie jest trik renderujący — to to, jak granice komponentów zamieniają pracę nad UI w mniejsze, bezpieczniejsze zmiany. Gdy komponent ma jasną odpowiedzialność i stabilną „powierzchnię publiczną” (props), zespoły mogą refaktoryzować wnętrze bez przymuszania przepisywania całej aplikacji. Ta stabilność ułatwia review kodu, zmniejsza przypadkowe awarie i pomaga nowym członkom zespołu zrozumieć, gdzie wprowadzać zmiany.
Przydatna mentalna metafora: dla danych props i stanu komponent powinien przewidywalnie opisać UI. Chociaż efekty uboczne i API przeglądarki istnieją, większość logiki komponentu może pozostać deterministyczna. Dlatego utrzymywalne testowanie Reacta często skupia się na zachowaniu i wyjściu:
Kontrole dostępności dobrze wpisują się tutaj: jeśli testujesz używając ról i dostępnych nazw, wykrywasz brakujące etykiety, złe stany fokusu i niespójne semantyki wcześnie. Spójność (linting, formatowanie, użycie systemu projektowego) wzmacnia tę samą ideę: przewidywalne komponenty są łatwiejsze w utrzymaniu.
Gdy komponenty wystawiają małe API propsów i ukrywają szczegóły implementacji, wiele osób może pracować równolegle — jedna osoba poprawia styl, inna zmienia pobieranie danych, kolejna aktualizuje testy — bez konfliktów.
Wydajność Reacta zwykle dotyczy nie tego, że „React jest wolny”, lecz ile pracy twoja aplikacja prosi przeglądarkę o wykonanie. Najszybsze UI robi jak najmniej: mniej węzłów DOM, mniej layoutów/przeliczeń, mniej drogich obliczeń i mniej rund sieciowych.
Częstym problemem są niepotrzebne ponowne renderowania: mała zmiana stanu powoduje ponowne renderowanie dużego poddrzewa, bo stan jest za wysoko lub dlatego, że propsy za każdym razem mają inną tożsamość (nowe obiekty/funkcje tworzone inline).
Innym klasykiem są ciężkie listy — setki lub tysiące wierszy z obrazkami, formatowaniem i handlerami. Nawet jeśli każdy wiersz jest „tani”, suma pracy rośnie i przewijanie staje się nieregularne.
Zacznij od struktury:
Skup się też na odczuciach użytkownika: zmniejsz opóźnienia wejścia, skróć czas do pierwszego znaczącego renderu i utrzymuj interakcje płynne. Poprawa 20 ms w często używanej interakcji może być ważniejsza niż skrócenie rzadko odwiedzanego ekranu o 200 ms.
Pochodny stan to dane, które możesz obliczyć z innych stanów/propsów (np. fullName z firstName + lastName, albo przefiltrowane elementy z listy + zapytania). Przechowywanie go często tworzy błędy: teraz masz dwa źródła prawdy, które mogą się rozjechać.
Wol preferować obliczanie wartości podczas renderu (lub memoizowanie obliczenia, jeśli jest drogie). Przechowuj tylko to, czego nie da się wyprowadzić — zazwyczaj wejście użytkownika, odpowiedzi serwera i intencje UI (np. „panel jest otwarty?”).
React nie tylko wprowadził ładniejszy sposób pisania UI; skłonił zespoły do reorganizacji tego, jak buduje się, udostępnia i utrzymuje frontend. Zanim komponenty stały się domyślnym modelem myślenia, wiele projektów traktowało UI jako strony z rozrzuconymi skryptami i szablonami. Dzięki Reactowi jednostką architektury coraz częściej stał się komponent: fragment UI z jasnym API (props) i przewidywalnym zachowaniem.
React wpasował się w erę aplikacji jednostronicowych (SPA). Gdy renderowanie jest napędzane stanem, „strona” przestaje być szablonem serwera i zaczyna być kompozycją komponentów plus routing po stronie klienta. To przesunięcie sprawiło, że kod zwykle strukturyzowano wokół obszarów funkcjonalnych i wielokrotnego użytku części UI, zamiast oddzielnych plików HTML.
Gdy UI buduje się z wielokrotnego użytku kawałków, naturalnym krokiem jest ich standaryzacja. Wiele organizacji przeszło od kopiowania markupów do budowania bibliotek komponentów: przyciski, kontrolki formularzy, modale, prymitywy layoutu i wzorce jak stany puste. Z czasem biblioteki te często ewoluowały w systemy projektowe — współdzielone komponenty plus wytyczne — dzięki czemu zespoły mogły dostarczać spójne doświadczenia bez wielokrotnego wynajdywania UI dla każdego ekranu.
Komponenty zachęcały zespoły do nadawania rzeczom tych samych nazw. Gdy wszyscy mówią o <Button>, <Tooltip> czy <CheckoutSummary>, dyskusje stają się bardziej konkretne: można omawiać zachowania i granice, a nie tylko wizualia. To wspólne słownictwo pomaga też szybciej wdrażać nowych członków zespołu, bo system jest odkrywalny przez kod.
Sukces Reacta wpłynął na to, jak szersza społeczność frontendowa myśli o UI: development „component-first”, deklaratywne renderowanie i przewidywalny przepływ danych stały się oczekiwaniami. Inne frameworki przyjęły podobne idee, nawet jeśli implementacja różni się szczegółami, bo praktyki te okazały się łatwiejsze do skalowania w realnych zespołach.
React zdobył renomę, ponieważ ułatwia ewolucję złożonych interfejsów, ale nie jest to rozwiązanie „za darmo”. Znając kompromisy z góry, zespoły mogą wdrażać go z właściwych powodów i unikać decyzji z gatunku "cargo-cult".
React ma krzywą uczenia się: komponenty, hooki i modele mentalne jak aktualizacje stanu czy efekty wymagają czasu, by je przyswoić. Nowoczesny React zwykle zakłada narzędzia do budowania (bundling, linting; TypeScript często, choć opcjonalnie), co dodaje konfiguracji i utrzymania. Wreszcie React wprowadza warstwy abstrakcji — biblioteki komponentów, routing, wzorce pobierania danych — które pomagają, ale też mogą ukryć złożoność, aż coś się zepsuje.
„React to tylko warstwa widoku.” Teoretycznie tak; w praktyce React mocno kształtuje twoją architekturę. Granice komponentów, własność stanu i wzorce kompozycji wpływają na przepływ danych i organizację kodu.
„Wirtualny DOM jest zawsze szybszy.” Wirtualny DOM przede wszystkim daje przewidywalność aktualizacji i lepszą ergonomię dla dewelopera. React może być szybki, ale wydajność zależy od wzorców renderowania, memoizacji, rozmiaru list i unikania niepotrzebnych renderów.
React dobrze sprawdza się w aplikacjach z wieloma interaktywnymi stanami, długotrwałymi bazami kodu i zespołami wielu deweloperów pracujących równolegle. Dla w większości statycznej strony marketingowej lub kilku małych widgetów prostsze rozwiązania (szablony serwerowe, lekki JS lub minimalne frameworki) mogą być łatwiejsze do wdrożenia i utrzymania.
Jeśli prototypujesz aplikację React i chcesz szybko zweryfikować te pomysły (granice komponentów, własność stanu, wzorce kompozycji), workflow vibe-coding może pomóc. Na przykład Koder.ai pozwala opisać funkcje w czacie i wygenerować działający frontend React razem z backendem Go/PostgreSQL, a potem iterować z migawkami/rollbackami i eksportować kod źródłowy, gdy będziesz gotowy przejąć projekt ręcznie. To praktyczny sposób na sprawdzenie decyzji architektonicznych na rzeczywistej funkcji zanim zobowiążesz się do pełnej budowy.
Następny krok: zaprototypuj jedną prawdziwą funkcję, zmierz złożoność i prędkość zespołu, a potem świadomie skaluj wzorce — nie domyślnie.
Jordan Walke stworzył React pracując w Facebooku. React miał znaczenie, ponieważ zastąpił kruche, ręczne „klejone” skrypty manipulujące DOM-em modelem opartym na komponentach i stanie — dzięki czemu złożone interfejsy stały się łatwiejsze do skalowania, debugowania i utrzymania.
Szablony mają tendencję do rozpraszania reguł UI pomiędzy markupiem a rozproszonymi handlerami zdarzeń ("gdy X się zdarzy, zaktualizuj Y"). Komponenty łączą UI i logikę za małym interfejsem (props), więc możesz budować funkcje z przewidywalnych kawałków zamiast łatek na stronie na przestrzeni czasu.
Komponent to wielokrotnego użytku element, który przyjmuje wejścia (zazwyczaj props) i zwraca to, jak powinien wyglądać UI dla tych wejść.
W praktyce warto dążyć do:
Props to wejścia, które przekazujesz do komponentu, by go skonfigurować (tekst, flagi, callbacki lub inny UI). Traktuj props jak kontrakt:
disabled, onSubmit) zamiast ogólnych obiektów „wszystko w jednym”Deklaratywny UI oznacza, że opisujesz co interfejs powinien pokazywać dla danego stanu, a nie jak krok po kroku zmieniać DOM.
Praktycznie:
JSX to składnia, która pozwala pisać strukturę UI przypominającą HTML wewnątrz JavaScriptu. Jest użyteczny, bo logika renderowania i kontrolowany przez nią markup żyją razem, co sprawia, że komponent jest łatwiejszy do przeczytania i przeglądu jako jedna całość.
Stan to dowolne dane, które mogą się zmieniać w czasie i powinny wpływać na to, co widzi użytkownik (tekst pola, status ładowania, zawartość koszyka itp.).
Praktyczne zalecenie: przechowuj źródło prawdy (wejście użytkownika, odpowiedzi z serwera, intencje UI), a resztę wyprowadzaj z tego (np. liczniki, przefiltrowane listy).
Jednokierunkowy przepływ danych oznacza:
To ułatwia debugowanie, bo możesz śledzić aktualizację krok po kroku: zdarzenie → zmiana stanu → ponowne renderowanie.
Wirtualny DOM to pamięciowa reprezentacja UI w React. Gdy stan/propsy się zmienią, React porównuje poprzedni opis UI z nowym i aktualizuje rzeczywisty DOM tylko tam, gdzie to konieczne.
Aby unikać typowych problemów:
key dla elementów listZacznij od prostoty i rozszerzaj w razie potrzeby:
Preferuj jedno źródło prawdy i wyprowadzaj pozostałe wartości, by zapobiec rozjazdom.