ReactJS *

Привет, Хабр! Я делаю TFile — сервис, который передаёт файлы напрямую между браузерами. Без регистрации, без установки, без загрузки файла на чей-то сервер. Расскажу, как он устроен и на какие грабли я наступил по дороге. Цифры в статье — из реальных замеров.

Два режима

⚡ Отправить сейчас. Открываете сайт, получаете ссылку вида tfile.io или QR-код. Второй человек открывает её, и дальше можно перетаскивать файлы, целые папки, текст и скриншоты из буфера обмена.

🔗 Поделиться позже. Выбираете файлы и получаете ссылку. Любой, кто её откроет, видит список и скачивает то, что ему нужно, когда ему удобно. Те, кто уже скачал, раздают куски дальше — как в торренте, только прямо в браузере.

Как идут байты

Сервер у TFile только сигнальный: небольшой WebSocket на Node.js, через который два браузера обмениваются SDP и ICE-кандидатами. Сами файлы идут по WebRTC data channel, а он всегда зашифрован (DTLS). Если прямое соединение не получается (строгий NAT, корпоративная сеть), трафик идёт через TURN-сервер (eturnal). Ему достаются уже зашифрованные данные: прочитать их он не может и ничего не хранит.

Чтобы было видно, что сервер не встал посередине, оба участника видят код безопасности: SHA-256 от DTLS-отпечатков обоих SDP, 40 бит, которые показываются как 12 цифр. Совпадают коды — сертификаты никто не подменял.

Грабли: SCTP и большие очереди

Первая версия просто писала в канал, пока bufferedAmount не дойдёт до 4 МБ. На loopback в Chrome оказалось, что SCTP отправляет всё накопленное разом: пачка около 2 МБ теряет пакеты, и передача стоит 2–3 секунды.

Представьте поиск по каталогу: поле ввода, а под ним список из тысяч товаров. Перестраивать такой список долго, и если делать это на каждое нажатие, поле начнёт тормозить. Поэтому обновление списка можно пометить как несрочное: тогда React покажет символ в поле сразу, а список перестроит потом, урывками, в промежутках между нажатиями клавиш.

Но что, если пользователь печатает без остановки: список не обновится никогда? И что видит пользователь, пока новый список считается или грузится с сервера, - старый список, пустой экран или спиннер?

Устанавливаю один hero-блок через production-registry shadcn в отдельный Next.js-проект. Разбираю три полученных файла, адаптацию через пропсы и проверки на ширинах от 320 до 1280 px. Один реальный опыт с кодом, замерами и ограничениями.

Привет, я фронтенд-разработчик, и сегодня хочу разобраться с одной интересной особенностью React Server Components.

Если вы работали с RSC, то наверняка замечали, что вокруг них почти всегда появляется ещё один участник — bundler. В документации React прямо говорится, что директивы вроде 'use client' дают инструкции bundler'ам, совместимым с RSC, а при встрече клиентского компонента bundler должен построить для него клиентскую сборку.

Но возникает вполне логичный вопрос. Зачем React Server Components вообще нужен bundler?

Ведь JavaScript уже умеет работать с модулями. Браузер понимает import, умеет загружать ES-модули и поддерживает динамический import().

На первый взгляд можно сделать всё достаточно просто.

Я веду несколько сайтов на Next.js, и по рабочим журналам на них чаще всего повторяются четыре SEO ошибки: полная копия сайта на www, код 200 вместо 404 на несуществующих адресах, теги title и canonical не там, где их ждет робот, и лишние параметры в адресах.

Знакомая ситуация: в контексте лежат два поля, скажем, name и age. Меняется age, и ререндерится компонент, который читает только name. У useContext нет селектора, как у useSelector в Redux: React сравнивает value провайдера целиком, а при каждом изменении это новый объект. Ни useMemo, ни React.memo тут не спасают.

В статье — небольшой контекст, где компонент ререндерится, только когда меняется его собственное поле. И разбор, почему он устроен именно так:

Почему через контекст стоит передавать не сами данные, а стабильный объект доступа к ним?

Почему обычные приёмы — useMemo на value и раздельные контексты — до этого не дотягивают?

Зачем для подписки нужен useSyncExternalStore и что такое tearing?

На каких деталях легко ошибиться и когда такой контекст вообще нужен?

WYSIWYG-редактор в Next.js App Router затрагивает несколько слоев приложения. Quill работает с DOM и browser API, поэтому сам редактор живет на клиенте. Контент нужно хранить отдельно от экземпляра Quill, передавать в компонент при смене сущности, сохранять на сервер и затем показывать без toolbar и режима редактирования.
Если хранить результат Quill как HTML, редактор и viewer могут работать с одной строкой contentHtml. Editor меняет HTML через onChange. Autosave отправляет новую версию после паузы во вводе. Viewer получает сохраненный HTML и отдельно обрабатывает элементы, которые Quill использует для code blocks. Для подсветки кода добавляется highlight.js.

Начиная с React 18 рендер можно прервать: срочные обновления обгоняют несрочные, даже если React уже взялся за несрочное. Если задуматься, вопросов много:

Как React посреди рендера отдаёт поток браузеру, чтобы тот обработал ввод, а потом продолжает с того же места?

Почему до React 16 он так не умел?

Кто решает, какие обновления срочные, и почему большинство рендеров не прерывается вообще?

Что происходит с незакоммиченными обновлениями, когда пришло что-то срочное?

И главное, как обновления, которые выстраиваются в очередь, не путаются в порядке, если срочное пришло позже, но должно обогнать несрочные?

Нас двое. Один недавно искал работу и ходил по собеседованиям, второй сам собеседует кандидатов и раз за разом видит, как люди спотыкаются на одних и тех же задачах: debounce, глубокое сравнение объектов, форма с валидацией.

Готовиться к таким задачам на русском оказалось почти негде, особенно если вы пишете на JS или TS не только во фронте, но и на бэке. Поэтому мы сделали ПаровоJSик. Под катом рассказываем, что внутри, как тесты запускаются прямо в браузере и что будет дальше.

Во время разработки библиотеки morphing-scroll я пришёл к необычному способу организации локальных данных в React-компоненте. Это не было заранее придуманной архитектурой. Я экспериментировал с обновлениями, постепенно убирал лишние состояния и в какой-то момент получил код, который оказался заметно проще прежнего. Для меня это стало настоящим открытием.

Я преподаю детям программирование и вижу одну и ту же картину: на обычных тренажёрах печати дети быстро устают, начинают отвлекаться, а некоторые просто просят выключить. Тренажёра для детей с дислексией я не нашла ни одного. Ждать, пока его кто-то придумает, я не стала и сделала свой — Клавитраж.

Идея пришла не только с занятий: у меня самой дислексия, и именно клавиатура когда-то помогла мне справиться с письмом. Как я живу с этим и почему печать стала для меня спасением, расскажу в отдельной статье.

Здесь — о том, что я придумала, что из этого сработало, а в чём я ошиблась.

Хабы: JavaScript, WebRTC, Разработка веб-сайтов, Сетевые технологии, Браузеры
Теги: webrtc, rtcdatachannel, sctp, turn, stun, opfs, compressionstream, p2p

Введение

Представьте, что вам нужно отрендерить в React-приложении таблицу с 100 000 объектов, которые непрерывно обновляются в реальном времени через WebSocket. Каждые 50 мс прилетает батч из 5000 дельт (изменений).

Стандартный подход с useState или классическим Redux (с Immer) убивает браузер за несколько секунд:

▎ Может он и быстр, только экосистема нулевая. Ну и ещё система модулей кастомная, что полностью убивает любые готовые инструменты. Так что $mol — по сути одной ногой в могиле.
▎ Был у меня сложный компонент, допустим weather_widget. И вот в 20 местах на него наложили оверрайды. А потом я пересобрал этот widget. Что произойдёт с оверрайдами, которые знают внутреннюю структуру зависимости? Правильно, всё пойдёт крахом.

▎ Вот вы реально готовы поставить свой доход на вот это?

На примере панели профиля вынесем логику и подготовку данных в useSetup[Component], а в компоненте оставим разметку. Затем отдельно проверим setup-хук, компонент через Shallowly и взаимодействие через React Testing Library. В конце — полный пример с Vitest, который можно забрать и запустить.

Если следить за React только по крупным релизам, легко пропустить момент, когда библиотека тихо меняет направление. React 19.3 — как раз такой случай. Сам релиз вышел 9 сентября 2026 года. И я хочу поделиться парой моментов из этого обновления. Рассмотрим пару хуков это ViewTransition и Fragment Refs. Еще, что я могу выделить, это новые возможности для SSR, Server Components и работы с браузерными API.

Зелёный тест на учебном стенде ещё ничего не гарантирует, на реальном проекте он может падать через раз.

Рассказываю о тренажёре, который начинается как обычный курс, а потом включает Hard Mode: надоедливые попапы, медленный бэкенд и промо, которое перекрывает экран в самый неудобный момент.

Что внутри: курс из 11 уроков, Hard Mode с воспроизводимыми флаками и Flake Score, который показывает, переживёт ли тест реальный проект.

Привет, Хабр! Меня зовут Егор Смирнов, я руководитель команды Backend for Frontend в VK. Одна из зон нашей ответственности — поддержка и развитие инфраструктуры для фронтенда ВКонтакте. 

Веб-версии ВКонтакте в 2026 году исполнилось 20 лет. За это время наш фронтенд прошёл путь от AJAX до современного веб-приложения. Раньше мы вручную манипулировали DOM, сборка иконок превращалась в приключение, а деплой и откат занимали по полчаса. К середине 2026 года мы выстроили масштабируемую архитектуру, в которой компоненты, сборка и деплой работают как единая система.

Как мы полностью переработали архитектуру ВКонтакте за три последних года, расскажу в этой статье.

Карточка в каталоге обычно ведёт на detail page. Для прямого перехода нужен отдельный URL вроде /events/123. Для просмотра нескольких карточек подряд удобнее оставить список на экране и открыть detail поверх него. Если modal хранится только в useState, адрес страницы не меняется. Прямую ссылку на открытый объект получить нельзя. После reload остаётся список, а поисковый робот видит только исходную страницу.
App Router поддерживает другую схему. Один detail URL открывается как modal при client-side переходе из списка и как обычная страница при прямом запросе или reload. Для этого используются Parallel Routes и Intercepting Routes. Next.js описывает тот же паттерн для modal поверх gallery или другого списка. В учебном EventMap этот маршрут используется для событий.

Организованная разработка фронтенда должна отвечать на три вопроса: компоненты, ререндеринг, стилизация. И LandTS легко на них отвечает.