#007 — React Fragment + WebRTC

Stream #007

Дата: 26 червня 2026 | 19:00 London / 21:00 Kyiv
Формат: Дві доповіді · ~60 хвилин
Гість: Олександр Блажейко
YouTube: https://youtube.com/live/leT3mUEmIqA

Учасники

Олег Левченко — Senior Full Stack JavaScript Developer (React / Node.js / AWS)
The AA · Cardiff, UK
YouTube @zloyleva · itfriday.community

Олександр Блажейко — Software Development Engineer · Fullstack, 7+ років досвіду
Україна
LinkedIn · itvibe.party

Ключові тези

Доповідь 1 — React Fragment · Олег Левченко

<></> компілюється у React.Fragment — не синтаксичний цукор, а повноцінний компонент; не додає жодного вузла в DOM, що критично для Flexbox/Grid і валідного HTML (наприклад, <tr> всередині <tbody>)
Shorthand vs explicit: <></> зручний, але не підтримує props; для key у .map() обовʼязково використовуй <Fragment key={...}> — без нього React не може відстежити елементи при зміні порядку, стан «прив'язується» до позиції, а не до елемента
Pitfall зі станом: <><Child /></> і <Child /> — React вважає за одне дерево; але <><><Child /></></> → <Child /> вже різні — зайвий рівень Fragment скидає стан дочірнього компонента
FragmentInstance (Canary): ref на <Fragment> повертає не DOM-вузол, а об'єкт FragmentInstance — без DOM-обгортки, але з методами для трьох задач
Events без wrapper: fragmentRef.current.addEventListener('click', handler) — один listener на всіх першорівневих DOM-дітей; removeEventListener і dispatchEvent теж підтримуються
Focus management: focus() знаходить перший focusable елемент у глибину (depth-first); focusLast() — останній; blur() знімає фокус якщо він всередині фрагмента — корисно для доступності при відкритті модальних вікон
observeUsing(observer): підключає IntersectionObserver, ResizeObserver або MutationObserver до всіх першорівневих DOM-дітей одним викликом; unobserveUsing для cleanup — без зайвого wrapper div

Доповідь 2 — WebRTC · Олександр Блажейко

WebRTC (Web Real-Time Communication) — відкритий стандарт W3C/IETF з 2021: аудіо, відео та довільні дані напряму між браузерами (peer-to-peer) без плагінів і посередників у медіапотоці
Дві фази: спершу учасники «знайомляться» через Signaling-сервер і STUN (SDP/ICE-обмін + публічні адреси), потім медіа та дані йдуть напряму між пристроями — сервери більше не задіяні
ICE / STUN / TURN: ICE перебирає всі можливі мережеві шляхи; STUN підказує пристрою його публічну адресу; TURN — резервний ретранслятор коли прямий P2P неможливий (Symmetric NAT)
Коли вистачає STUN: Full Cone, Restricted Cone, Port-Restricted NAT — hole punching прокладає прямий канал; Symmetric NAT з обох сторін — вмикається TURN, ретрансляція через сервер
Три ключові API: getUserMedia() — доступ до камери/мікрофона; RTCPeerConnection — серце WebRTC: з'єднання, NAT-обхід, шифрування; RTCDataChannel — двонапрямний канал для текстів, файлів, стану гри
Signaling: WebRTC не диктує протокол — можна WebSocket, HTTP, SIP або будь-який інший; Peer A надсилає offer (SDP), Peer B відповідає answer, потім обмін ICE-кандидатами
Шифрування обов'язкове: DTLS — handshake прямо в P2P-каналі, звіряє сертифікати і узгоджує ключі; SRTP шифрує кожен медіапакет на цих ключах; незашифрованого режиму немає
Debugging у Chrome: chrome://webrtc-internals — жива статистика (бітрейт, втрати пакетів, jitter, RTT), стан ICE-кандидатів, повні SDP offer/answer, дамп у файл; getStats() API для власного моніторингу
Виклики: P2P погано масштабується на великі групи → SFU-архітектура (медіасервери); TURN-сервери платні при симетричному NAT; нюанси сумісності між реалізаціями

Таймкоди

Будуть додані після стріму.

#007 — React Fragment + WebRTC ​

Учасники ​

Ключові тези ​

Доповідь 1 — React Fragment · Олег Левченко ​

Доповідь 2 — WebRTC · Олександр Блажейко ​

Таймкоди ​