JSX to nie HTML wewnątrz JavaScriptu — to krok kompilacji.

Pytanie 1

Otwierając nowy projekt React i czytając plik App.jsx, często spotykamy ten sam zaskoczenie: plik jest napisany w JavaScript, a mimo to zawiera kod, który wygląda identycznie jak HTML. Pierwszy rzut oka na komponent zwracający element <h1> nasuwa pytanie, czy silnik języka w jakiś sposób nauczył się analizować tagi.

Zanim będziesz czytać dalej, zdecyduj, czy zwykły JavaScript potrafi to zrozumieć:

const heading = <h1>Hello World</h1>;

• A) Tak
• B) Nie

Prawidłowa odpowiedź to B) Nie. Standardowy silnik JavaScript nie posiada gramatyki dla elementu <h1>. Gdy wkleimy ten sam kod do pliku .js bez żadnej modyfikacji, parser zgłosi błąd składniowy.

React nigdy nie wysyła JSX bezpośrednio do przeglądarki. W pierwszym kroku procesu budowania kod jest przekształcany na zwykłe wywołania funkcji. Koncepcyjnie proces ten wygląda następująco:

You write JSX
      │
      ▼
Compiler (Babel / Vite)
      │
      ▼
JavaScript
      │
      ▼
Browser

Tylko JavaScript dociera do przeglądarki. Tagi, które wpisałeś, nigdy nie pojawiają się w odpowiedzi sieciowej jako JSX.

Pomyśl o tym jak o Google Translate

Wyobraź sobie napisanie listu po francusku dla przyjaciela, który czyta tylko po angielsku. Przyjaciel nagle nie zrozumie francuskiego; pomiędzy nimi znajduje się tłumacz. JSX działa w ten sam sposób. Tworzysz składnię przypominającą HTML, kompilator (Babel, SWC lub transformacja w Vite) przekształca ją na JavaScript, a dopiero wtedy przeglądarka ją wykonuje.

Czym więc dokładnie jest JSX?

Początkujący często opisują JSX jako „HTML wewnątrz JavaScriptu”. To uproszczenie jest błędne. JSX przypomina HTML, ale nie jest nim. Dokładniejsza definicja: JSX to rozszerzenie składni JavaScriptu, które umożliwia opisywanie interfejsu użytkownika przy użyciu struktury podobnej do HTML. Kluczowym słowem jest podobna do HTML – a nie sam HTML. Nazwy atrybutów się różnią (className zamiast class), a otaczające je wyrażenia znajdują się w systemie wartości JavaScriptu, a nie w odrębnym języku znaczników.

Dlaczego powstał JSX?

Bez JSX ten sam nagłówek:

<h1>Hello React</h1>

będzie wyrażony za pomocą nawiasowanych wywołań funkcji:

React.createElement(
  "h1",
  null,
  "Hello React"
);

Strona napisana w ten sposób staje się trudna do przeglądania. JSX istnieje po to, aby struktura interfejsu użytkownika pozostawała czytelna, podczas gdy kompilator w tle generuje wywołania React.createElement (lub równoważne).

Pytanie 2

Czym to się wyświetla?

const name = "Ananya";

function App() {
  return (
    <h1>Hello {name}</h1>
  );
}

• A) Cześć {name}
• B) Cześć Ananya
• C) Błąd składniowy

Odpowiedź to B) Cześć Ananya. Nawiasy falcowane informują JSX, aby przerwało tryb zapisu markup i wykonało wyrażenie w JavaScript. Wartość name jest wstawiana do nagłówka, więc interfejs pokazuje ciąg znaków, a nie składnię nawiasów.

Nawiasy falcowane pełnią jedną funkcję

Za każdym razem, gdy JSX widzi {…}, wykona wyrażenie znajdujące się wewnątrz i wstawi jego wynik. To cała zasada: uruchomić JavaScript i umieścić uzyskaną wartość. Nie istnieje drugi tryb dla instrukcji ani bloków o efektach ubocznych.

Zadanie 3

Które treści nawiasów są dozwolone w JSX?

• A) odniesienie do zmiennej, np. {name}
• B) wyrażenie arytmetyczne, np. {10 + 20}

C) blokowy if napisany wewnątrz nawiasów

D) wyrażenie ternarne, które wybiera między "Adult" a "Minor" na podstawie wartości z age

A, B i D działają. C nie działa. JSX przyjmuje tylko wyrażenia, które dają określoną wartość. Sam if to instrukcja i nie dostarcza nic do umieszczenia w strukturze drzewa; wyrażenie ternarne zwraca wartość, dlatego sprawdzenie wieku w opcji D jest poprawne, natomiast C zostaje odrzucone.

Ostateczne uwagi

JSX może wydawać się czymś magicznym od samego początku: wygląda tak, jakby HTML i JavaScript połączyły się w jeden język. Jego mechanizmy są prostsze – JSX to swego rodzaju „cukier” dla programistów. Zanim aplikacja zostanie uruchomiona w przeglądarce, kompilator przepisuje ją na zwykły JavaScript. Gdy ten proces stanie się jasny, składnia markup-in-JS przestaje być myląca i staje się czytelnym sposobem opisywania struktur interfejsu użytkownika.