Context

Než začneme: vzkaz přes celou školu, nebo rozhlas?

Ředitel školy potřebuje říct žákům ve třetím patře, že odpoledne odpadá tělocvik. Bez rozhlasu by to šlo takhle: ředitel to řekne zástupkyni, ta učiteli na chodbě, ten třídnímu učiteli, a ten konečně žákům. Zástupkyně ani učitel na chodbě tu zprávu nepotřebují – musí ji jen nést dál. A když někdo v řadě zapomene, zpráva se ztratí.

V Reactu se tomu říká prop drilling (provrtávání props). Data tečou jen shora dolů přes props, takže když je potřebuje komponenta hluboko ve stromu, musí je nést každá komponenta mezi nimi – i ta, která je vůbec nepoužívá.

Škola to řeší rozhlasem. Ředitel mluví do mikrofonu v ústředně a slyší ho každý, kdo je v budově a má reproduktor. Nikdo nic nenese. Přesně tohle je Context:

• Provider je ústředna rozhlasu – komponenta nahoře ve stromu, která „vysílá“ hodnotu.
• use(Context) je reproduktor – kterákoli komponenta pod Providerem si hlášení poslechne.
• Komponenty mezi nimi o hlášení vůbec nevědí.

1. Problém: prop drilling

Aplikace má přihlášeného uživatele. Jeho avatar se ukazuje v postranním panelu, který je uvnitř layoutu, který je uvnitř aplikace:

function App() {
  const [user, setUser] = useState<User>(…)
  return <Layout user={user} />
}

function Layout({ user }: { user: User }) {      // nepotřebuje, jen nese dál
  return <Sidebar user={user} />
}

function Sidebar({ user }: { user: User }) {     // nepotřebuje, jen nese dál
  return <Avatar user={user} />
}

function Avatar({ user }: { user: User }) {      // konečně ho použije
  return <img src={user.photo} alt={user.name} />
}

Proč to vadí:

• Layout a Sidebar musí znát typ User a mít prop, který nepotřebují.
• Když bude uživatele potřebovat ještě tlačítko v hlavičce, přidáváš prop do další řady komponent.
• Přejmenování nebo změna typu znamená upravit všechny komponenty v řadě.

Dvě nebo tři úrovně jsou v pořádku – props jsou jasné a čitelné. Problém začíná, když se stejná data nesou přes hodně vrstev k hodně místům.

2. Context krok za krokem

Postavíme rozhlas pro barevné téma (světlé/tmavé), které chce znát spousta komponent.

Krok 1: postav ústřednu

const ThemeContext = createContext<{ theme: Theme; toggle: () => void } | null>(null)

createContext vytvoří „kanál“. Hodnota v závorce (null) je to, co uslyší komponenta, která je mimo dosah jakéhokoli Provideru – reproduktor bez signálu.

Krok 2: zapni vysílání

function ThemeProvider({ children }: { children: ReactNode }) {
  const [theme, setTheme] = useState<Theme>('light')
  const toggle = () => setTheme((t) => (t === 'light' ? 'dark' : 'light'))

  return <ThemeContext value={{ theme, toggle }}>{children}</ThemeContext>
}

// Někde nahoře v aplikaci:
<ThemeProvider>
  <Layout />
</ThemeProvider>

• Provider je obyčejná komponenta, která má stav (téma) a vysílá ho spolu s funkcí na změnu. Context sám nic nepamatuje – jen doručuje.
• <ThemeContext value={…}> je v Reactu 19 zápis Provideru. Ve starším kódu uvidíš <ThemeContext.Provider value={…}>.
• Vysílání slyší jen komponenty uvnitř – všechno, co je v children, a jejich potomci.

Krok 3: reproduktor jako vlastní hook

function useTheme() {
  const ctx = use(ThemeContext)
  if (!ctx) throw new Error('useTheme musí být uvnitř <ThemeProvider>')
  return ctx
}

// Kdekoli hluboko ve stromu:
function ThemedButton() {
  const { theme, toggle } = useTheme()
  return <button className={theme} onClick={toggle}>Přepnout</button>
}

Proč vlastní hook a ne rovnou use(ThemeContext) v každé komponentě? Když někdo zapomene obalit aplikaci Providerem, bez kontroly by dostal null a o pár řádků dál nesrozumitelnou chybu „cannot read properties of null“. S hookem dostane jasnou zprávu, co je špatně. Navíc komponenty nemusí vědět, jak je kontext uvnitř postavený.

Co se stane po kliknutí na „Přepnout“

1. toggle() zavolá setTheme v Provideru. Změnil se stav Provideru.
2. Provider se překreslí a vyšle nový objekt { theme: "dark", toggle }.
3. React najde všechny komponenty, které kontext poslouchají, a překreslí je s novou hodnotou. Layout mezi nimi se nemusí překreslovat kvůli kontextu – nic z něj nečte.

3. Kdy Context použít (a kdy ne)

Rozhlasem se hlásí věci, které zajímají celou školu: konec vyučování, požární poplach. Kdyby se rozhlasem řešilo, kdo komu půjčil gumu, nikdo by se neslyšel. Context se hodí na data, která potřebuje hodně míst a která se mění zřídka.

Než sáhneš po kontextu, zkus kompozici

Někdy jde o to, že zprávu nesou lidé, kteří ji vůbec nést nemusí. Místo rozhlasu stačí posadit žáka přímo do ředitelny. V Reactu: místo abys data protlačoval přes Layout, předej mu hotový prvek, který už data má:

// ❌ Layout nese user jen proto, aby ho předal dál
<Layout user={user} />

// ✅ Avatar vytvoříš tam, kde user je. Layout jen určí, KDE se ukáže.
<Layout sidebar={<Avatar user={user} />} />

function Layout({ sidebar }: { sidebar: ReactNode }) {
  return <div className="layout"><aside>{sidebar}</aside>…</div>
}

Layout teď o uživateli neví nic – a nepotřebuje k tomu ani Context. Tohle je sloty z lekce o základech.

4. Výkon: kdo se překreslí?

Rozhlas má jednu nevýhodu: když se hlášení změní, poslouchat musí všichni, i když se jich týká jen kousek. Hlásí se „tělocvik odpadá a v jídelně jsou knedlíky“ – a kvůli knedlíkům zpozorní i třída, která tělocvik vůbec nemá.

Context funguje stejně. Když Provider vyšle novou hodnotu (React to pozná porovnáním reference), překreslí se všichni, kdo kontext čtou – i ti, kteří používají jen část hodnoty.

function AppProvider({ children }: { children: ReactNode }) {
  const [count, setCount] = useState(0)
  // Při každé změně count vznikne NOVÝ objekt → všichni posluchači se překreslí
  return <AppContext value={{ user: 'Jana', count, inc }}>{children}</AppContext>
}

function UserBadge() {
  const { user } = use(AppContext)  // čte jen user…
  return <span>{user}</span>         // …ale překreslí se i při každé změně count
}

Řešení: místo jednoho kanálu použij víc kanálů – kontext pro každou věc, která se mění zvlášť.

Oddělený stav a akce

Častý a velmi účinný vzor je spojit Context s reducerem z minulé lekce. Stav vysílá jeden kanál, funkci dispatch druhý. dispatch se nikdy nemění, takže komponenty, které jen posílají akce (tlačítka „Přidat“), se při změně dat nepřekreslují:

const TasksContext = createContext<Task[] | null>(null)
const TasksDispatchContext = createContext<Dispatch<Action> | null>(null)

function TasksProvider({ children }: { children: ReactNode }) {
  const [tasks, dispatch] = useReducer(tasksReducer, [])
  return (
    <TasksContext value={tasks}>
      <TasksDispatchContext value={dispatch}>{children}</TasksDispatchContext>
    </TasksContext>
  )
}

function AddTaskButton() {
  const dispatch = useTasksDispatch()   // poslouchá jen kanál, který se nemění
  return <button onClick={() => dispatch({ type: 'added', text: 'Nový' })}>Přidat</button>
}

Ověř si to

Rozcvička

VÝZVA: Barva z kontextu

Kontext s barvou je založený a App ho poskytuje (value="tomato").

1. V komponentě ColoredText si barvu přečti: const color = use(ColorContext)
   a použij ji ve stylu: style={{ color }}

ColoredText nedostává žádné props – barvu si vezme sama z kontextu.

Výzvy

První výzva procvičí kapitolu 2 – celý vzor Provider + hook. Druhá kapitolu 4: kontext jako „služba“, který vysílá jen funkci, takže komponenty, které notifikace vyvolávají, se nepřekreslují.

VÝZVA: Přihlášení přes Context

Komponenty Header, SecretContent a AdminPanel jsou hotové a berou si data z useAuth().
Ty dopíšeš Provider a hook, aby to opravdu fungovalo.

1. AuthProvider: vytvoř stav `user` (User | null, začíná null) a sestav `value`:
     login(name) → setUser({ name, role: name === 'admin' ? 'admin' : 'user' })
     logout()    → setUser(null)
2. AuthProvider: obal `children` do <AuthContext value={value}>.
3. useAuth(): přečti kontext přes use(AuthContext). Když je null (hook je mimo Provider),
   vyhoď srozumitelnou chybu: throw new Error('useAuth() musí být uvnitř <AuthProvider>').

Všimni si: Page mezi AuthDemo a Headerem nedostává žádné props o uživateli.