Praca programisty to ciągła podróż przez nowe technologie, frameworki i paradygmaty. Kilka lat temu, gdy zaczynałem swoją przygodę z frontendem, nieśmiało zagłębiałem się w świat ASP.NET Web Forms, HTML, CSS i JavaScript. Z czasem moja droga zaprowadziła mnie do Angulara – frameworka, który poznawałem systematycznie, dokumentując swoją wiedzę w serii wpisów na tym blogu.

Rekrutując się do nowej firmy, miałem już pewne doświadczenie z Angularem, które było weryfikowane podczas rozmowy kwalifikacyjnej. Wszystko szło dobrze, jednak szybko okazało się, że główny stack technologiczny w tej firmie to... React. I tutaj stanąłem przed wyborem: czy trzymać się tego, co znam, czy zanurzyć się w nową technologię, aby bardziej świadomie i efektywnie wykonywać swoją pracę?

Wybór był oczywisty. Jako programista dążący do miana Full Stack Developera, wiedziałem, że znajomość różnych technologii frontendowych to nie tylko przewaga na rynku pracy, ale także sposób na zrozumienie różnych podejść do rozwiązywania tych samych problemów. Dlatego właśnie powstaje ta seria – chcę podzielić się z Wami moją drogą poznawania Reacta, ale nie samego Reacta, a React z TypeScript.

Dlaczego od razu TypeScript? Bo jeśli już przygotowałem dla Was obszerną serię o TypeScript, to naturalnym krokiem jest wykorzystanie tej wiedzy w praktyce. React + TypeScript to połączenie, które dominuje w profesjonalnych projektach, zapewnia type safety, lepsze wsparcie IDE i znacząco zmniejsza liczbę błędów runtime'owych. To jest właśnie to, czego potrzebujemy jako Full Stack Developerzy.

React to biblioteka JavaScript (a właściwie TypeScript w naszym przypadku) stworzona przez Facebook w 2013 roku, służąca do budowania interfejsów użytkownika. Zwróćcie uwagę na słowo "biblioteka", a nie "framework" – to istotna różnica w porównaniu do Angulara.

React skupia się przede wszystkim na warstwie widoku (View w architekturze MVC), dając programiście swobodę w wyborze pozostałych elementów stosu technologicznego. Nie narzuca router'a, sposobu zarządzania stanem czy struktury projektu – to Ty decydujesz, jakie narzędzia dodasz do swojego projektu. Dla niektórych to zaleta (elastyczność), dla innych wada (brak "out of the box" rozwiązań).

Główne cechy React:

• Komponentowa architektura – budujemy aplikację z małych, reużywalnych elementów
• Virtual DOM – efektywne renderowanie zmian w interfejsie
• Jednokierunkowy przepływ danych – dane płyną od rodzica do dziecka (top-down)
• JSX/TSX – rozszerzenie składni pozwalające pisać "HTML w JavaScript/TypeScript"
• Deklaratywność – opisujemy JAK ma wyglądać UI, a nie KROK PO KROKU jak go zbudować

Skoro mamy za sobą serię o Angularze, warto poświęcić chwilę na porównanie tych dwóch technologii. Nie chodzi o to, która jest lepsza – obie mają swoje miejsce w ekosystemie webowym – ale o zrozumienie różnic w podejściu.

Framework vs Biblioteka

Angular to kompleksowy framework. Instalując Angular dostajesz wszystko: routing, HTTP client, formularze, dependency injection, CLI, strukturę projektu. To jak przeprowadzka do w pełni umeblowanego mieszkania – wszystko jest, tylko musisz się nauczyć gdzie co leży.

React to biblioteka. Dostajesz narzędzie do budowania UI i... tyle. Routing? Zainstaluj React Router. Zarządzanie stanem? Wybierz: Context API, Redux, Zustand, MobX. HTTP? Fetch, Axios, React Query. To jak przeprowadzka do pustego mieszkania – masz swobodę, ale musisz sam dobrać meble.

TypeScript

Angular od wersji 2+ jest napisany w TypeScript i TypeScript jest tu językiem pierwszego wyboru. Nie ma opcji "może być JavaScript" – to TypeScript i już.

React pierwotnie był biblioteką JavaScript, ale TypeScript stał się de facto standardem w profesjonalnych projektach. Możesz używać czystego JavaScript, ale w 2024/2025 roku większość firm wybiera TypeScript dla type safety i lepszej maintainability.

Struktura i filozofia

Angular narzuca strukturę: moduły, komponenty, serwisy, dyrektywy, pipe'y. Wszystko ma swoje miejsce i nazwę. To podejście "opinionated" – Angular ma zdanie jak powinna wyglądać aplikacja.

React jest "unopinionated". Struktura projektu? Twoja decyzja. Nazewnictwo plików? Jak chcesz. Organizacja komponentów? Wymyśl własną. Ta swoboda może być zarówno błogosławieństwem, jak i przekleństwem.

Dependency Injection

Angular ma wbudowany DI container. Serwisy są singletonami (lub nie – jak zdecydujesz przez providedIn), inject'ujesz je w konstruktorze i działa.

React nie ma wbudowanego DI. Masz Context API do przekazywania danych przez drzewo komponentów, ale to nie to samo co pełnoprawny DI. Można oczywiście zaimplementować własny DI, ale to nie jest "React way".

Krzywa uczenia się

Angular ma stromą krzywą. Musisz nauczyć się wielu konceptów jednocześnie: modułów, decoratorów, RxJS, Dependency Injection, Angular CLI. To potężny framework i potrzeba czasu, aby go poznać.

React ma łagodniejszą krzywą na początku. Komponenty, props, state – to podstawy, które można ogarnąć w weekend. Jednak gdy aplikacja rośnie i musisz dodać routing, zarządzanie stanem, optymalizację – okazuje się, że i tu jest sporo do nauki.

Który wybrać?

Oba są świetne. Angular sprawdza się w dużych, korporacyjnych projektach gdzie potrzebna jest jednolita struktura i "wszystko out of the box". React dominuje w startupach i firmach ceniących elastyczność. Ale prawda jest taka, że jako Full Stack Developer powinieneś znać oba.

W internecie znajdziecie tysiące tutoriali "React dla początkujących", które zaczynają od czystego JavaScript. Dlaczego my od razu bierzemy TypeScript?

1. Profesjonalne projekty używają TypeScript

Sprawdźcie oferty pracy. "React Developer" vs "React + TypeScript Developer". Druga opcja pojawia się znacznie częściej w ogłoszeniach dla mid/senior developerów. TypeScript nie jest już nice-to-have, to must-have.

2. Mamy już fundament

Przygotowałem dla Was obszerną serię o TypeScript. Znacie typy, interfejsy, generics, utility types. Dlaczego mielibyśmy zaczynać od JavaScript, skoro możemy od razu wykorzystać tę wiedzę w praktyce?

3. Type Safety = mniej błędów

TypeScript wyłapuje błędy przed uruchomieniem aplikacji. Przekazałeś zły typ props? Kompilator Ci to powie. Próbujesz odwołać się do nieistniejącej właściwości? TypeScript nie pozwoli. W JavaScript te błędy ujawnią się dopiero w runtime, często już na produkcji.

4. Lepsze wsparcie IDE

IntelliSense, autouzupełnianie, refactoring – wszystko działa lepiej z TypeScript. Visual Studio Code (a właśnie jego polecam do Reacta) ma fenomenalne wsparcie dla TypeScript. Pisanie kodu staje się przyjemnością.

5. Samodokumentujący się kod

Interfejs Props w komponencie to najlepsza dokumentacja. Od razu wiesz jakie dane komponent przyjmuje, jakie są ich typy, co jest opcjonalne, a co wymagane.

interface ButtonProps {
  label: string;
  onClick: () => void;
  variant?: 'primary' | 'secondary';
  disabled?: boolean;
}

Spójrz na powyższy interfejs. Bez czytania dokumentacji wiesz wszystko o tym komponencie.

Zanim zaczniemy kodować, musimy zrozumieć co znajduje się w ekosystemie React. W przeciwieństwie do Angulara, tutaj mamy większą swobodę wyboru narzędzi.

Node.js i npm

Node.js to środowisko uruchomieniowe JavaScript (i TypeScript po transpilacji). Potrzebujemy go do uruchamiania narzędzi developerskich, build tools i lokalnego serwera developerskiego.

npm (Node Package Manager) to menadżer pakietów dla ekosystemu JavaScript. Przez npm instalujemy React, TypeScript, React Router i wszystkie pozostałe biblioteki. To odpowiednik NuGet dla .NET.

Vite – nasz build tool

W świecie React mamy kilka opcji do wyboru dla setupu projektu:

• Create React App (CRA) – oficjalne narzędzie od React, długo było standardem
• Vite – nowoczesny, błyskawiczny build tool
• Next.js – framework do React z server-side rendering
• Gatsby – generator statycznych stron oparty o React

My wybierzemy Vite. Dlaczego? Bo jest szybki (naprawdę, naprawdę szybki), nowoczesny, ma świetne wsparcie dla TypeScript out of the box i jest aktualnie najczęściej wybieranym narzędziem w nowych projektach React. Create React App, choć popularny, przestał być aktywnie rozwijany.

TypeScript

O TypeScript mówiliśmy już wiele w poprzedniej serii. Tutaj wykorzystamy go do typowania komponentów, props, state, eventów i wszystkiego co napotkamy w React.

React DevTools

Oficjalne rozszerzenie do przeglądarki (Chrome, Firefox) pozwalające na inspekcję drzewa komponentów React, sprawdzanie props, state, profilowanie wydajności. Must-have dla każdego React developera.

Jedną z kluczowych koncepcji React jest Virtual DOM. Czym to jest i dlaczego jest ważny?

Problem z DOM

Bezpośrednie manipulowanie DOM (Document Object Model) w przeglądarce jest kosztowne. Każda zmiana w DOM może wywołać reflow i repaint całej strony, co wpływa na wydajność. W tradycyjnym JavaScript (czy jQuery) często robimy coś takiego:

document.getElementById('counter').innerHTML = count;

Dla małych aplikacji to nie problem. Ale gdy mamy setki elementów, które zmieniają się dynamicznie, wydajność drastycznie spada.

Rozwiązanie React: Virtual DOM

React tworzy wirtualną reprezentację DOM w pamięci (JavaScript object). Gdy stan aplikacji się zmienia, React:

1. Tworzy nowy Virtual DOM
2. Porównuje go ze starym (proces zwany "diffing")
3. Oblicza minimalne zmiany potrzebne do zaktualizowania prawdziwego DOM
4. Aktualizuje tylko te elementy, które rzeczywiście się zmieniły

Ten proces nazywamy reconciliation (rekoncyliacja).

Dlaczego to jest szybkie?

Operacje na JavaScript objects są wielokrotnie szybsze niż operacje na DOM. React może wykonać tysiące porównań w Virtual DOM zanim zaktualizuje prawdziwy DOM – i robi to wszystko za Ciebie, automatycznie.

Nie musisz myśleć "jak zaktualizować DOM". Myślisz "jak powinien wyglądać UI dla tego stanu danych" – a React zajmie się resztą. To jest właśnie programowanie deklaratywne.

React, podobnie jak Angular, jest narzędziem do budowania Single Page Applications (SPA). Przypomnijmy sobie czym to jest.

W tradycyjnych aplikacjach webowych każde kliknięcie w link powoduje:

1. Wysłanie requestu do serwera
2. Serwer generuje nowy HTML
3. Cała strona się przeładowuje
4. Tracisz stan aplikacji (chyba że użyjesz cookies/session)

W SPA:

1. Ładujesz aplikację raz (bundle JavaScript/TypeScript)
2. Nawigacja odbywa się bez przeładowania strony
3. Zmieniają się tylko odpowiednie części UI
4. Stan aplikacji jest zachowany w pamięci
5. Dane pobierane są przez API (najczęściej REST lub GraphQL)

Przykłady SPA: Gmail, Facebook, Twitter, Netflix, Spotify Web Player.

React + React Router daje nam wszystko czego potrzebujemy do budowy SPA. Routing jest po stronie klienta (client-side routing), co oznacza, że zmiana URL nie powoduje request do serwera – JavaScript przechwytuje nawigację i renderuje odpowiedni komponent.

Czas przygotować nasze środowisko do pracy z React + TypeScript. Zakładam, że macie już zainstalowany Visual Studio Code (jeśli nie – gorąco polecam moje wcześniejsze wpisy na jego temat).

1. Instalacja Node.js

Pobierz Node.js ze strony nodejs.org. Wybierz wersję LTS (Long Term Support). W momencie pisania tego artykułu to wersja 24.x.

Po instalacji sprawdź w terminalu:

node --version
npm --version

Powinieneś zobaczyć numery wersji.

2. Visual Studio Code i rozszerzenia

VS Code to idealne narzędzie do pracy z React. Zainstaluj następujące rozszerzenia:

• ES7+ React/Redux/React-Native snippets – snippety dla React
• ESLint – linting kodu
• Prettier – formatowanie kodu
• TypeScript React code snippets – snippety TypeScript dla React
• Auto Rename Tag – automatyczne zmiany tagów
• Bracket Pair Colorizer 2 – kolorowe nawiasy (ułatwia czytanie kodu)

3. Tworzenie pierwszego projektu

Otwórz terminal i wykonaj:

npm create vite@latest my-react-app -- --template react-ts

Co się dzieje? Polecenie npm create vite@latest tworzy nowy projekt używając Vite. Parametr my-react-app to nazwa projektu, a --template react-ts oznacza, że chcemy szablon React z TypeScript.

Następnie:

cd my-react-app
npm install
npm run dev

Vite uruchomi serwer developerski (zazwyczaj na porcie 5173). Otwórz przeglądarkę i wejdź na http://localhost:5173.

Gratulacje! Właśnie uruchomiłeś swoją pierwszą aplikację React + TypeScript! 🎉

4. Struktura projektu

Po utworzeniu projektu zobaczysz następującą strukturę:

my-react-app/
├── node_modules/       # Zainstalowane pakiety npm
├── public/            # Pliki statyczne
├── src/               # Kod źródłowy aplikacji
│   ├── assets/        # Obrazki, fonty, itp.
│   ├── App.tsx        # Główny komponent
│   ├── App.css        # Style dla App
│   ├── main.tsx       # Entry point aplikacji
│   └── vite-env.d.ts  # Typy TypeScript dla Vite
├── .gitignore
├── index.html         # HTML template
├── package.json       # Zależności projektu i scripts
├── tsconfig.json      # Konfiguracja TypeScript
└── vite.config.ts     # Konfiguracja Vite

Najważniejsze pliki:

package.json – definiuje zależności projektu i npm scripts. Tutaj znajdziesz polecenia npm run dev, npm run build, itp.

tsconfig.json – konfiguracja TypeScript. Definiuje jak kod TypeScript będzie kompilowany do JavaScript.

vite.config.ts – konfiguracja Vite. Możesz tutaj dodać aliasy, pluginy, zmienić port serwera dev, itp.

src/main.tsx – entry point aplikacji. To tutaj React "montuje się" do DOM.

src/App.tsx – główny komponent aplikacji. Stąd będziemy budować naszą aplikację.

Otwórzmy src/main.tsx:

import React from 'react'
import ReactDOM from 'react-dom/client'
import App from './App.tsx'
import './index.css'

ReactDOM.createRoot(document.getElementById('root')!).render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
)

Co tu się dzieje?

1. Importy – importujemy React, ReactDOM, komponent App i style
2. createRoot – tworzymy "root" dla naszej aplikacji React
3. document.getElementById('root') – znajdujemy element w HTML o id="root"
4. wykrzyknik (!) – TypeScript non-null assertion operator (mówimy TS "wiem że ten element istnieje")
5. render – renderujemy nasz komponent App
6. React.StrictMode – tryb strict, który pomaga wykrywać potencjalne problemy

Teraz src/App.tsx:

import { useState } from 'react'
import reactLogo from './assets/react.svg'
import viteLogo from '/vite.svg'
import './App.css'

function App() {
  const [count, setCount] = useState(0)

  return (
    <>
      <div>
        <a href="https://vitejs.dev" target="_blank">
          <img src={viteLogo} className="logo" alt="Vite logo" />
        </a>
        <a href="https://react.dev" target="_blank">
          <img src={reactLogo} className="logo react" alt="React logo" />
        </a>
      </div>
      <h1>Vite + React</h1>
      <div className="card">
        <button onClick={() => setCount((count) => count + 1)}>
          count is {count}
        </button>
        <p>
          Edit <code>src/App.tsx</code> and save to test HMR
        </p>
      </div>
      <p className="read-the-docs">
        Click on the Vite and React logos to learn more
      </p>
    </>
  )
}

export default App

Nie przejmuj się jeśli nie wszystko jest jasne. To właśnie będziemy omawiać w kolejnych wpisach:

• useState – hook do zarządzania stanem
• <>...</> – Fragment (pozwala zwrócić wiele elementów)
• JSX/TSX – składnia podobna do HTML, ale w TypeScript
• onClick – obsługa eventów

To był pierwszy, wprowadzający wpis do serii o React + TypeScript. Omówiliśmy:

• Dlaczego React i dlaczego TypeScript od razu
• Różnice między React a Angular (dla tych, którzy przeszli moją serię o Angularze)
• Czym jest React i jakie są jego kluczowe koncepty (Virtual DOM, SPA)
• Ekosystem React i narzędzia, których będziemy używać
• Instalację środowiska i stworzenie pierwszego projektu

W kolejnym wpisie zagłębimy się w strukturę projektu React, poznamy JSX/TSX, stworzymy nasze pierwsze komponenty i nauczymy się jak przekazywać dane między nimi przez props. Zaczniemy budować solidne fundamenty, które pozwolą nam w przyszłości tworzyć zaawansowane aplikacje z pełną integracją z backend API.

Jeśli jeszcze nie znasz TypeScript, zachęcam do przeczytania mojej wcześniejszej serii o TypeScript – to będzie solidny fundament do tej serii. Jeśli już go znasz – doskonale! Wykorzystamy tę wiedzę w pełni.

Do zobaczenia w kolejnym wpisie! 🚀