System Design: frontend

Разберём реальную задачку, её дали мне на собес в Яндекс Поиск. Пользователь вбивает в поиск «2+2», в выдаче нужно показать блок-калькулятор с уже посчитанным ответом, отрисовка серверная. Как реализуешь?

Есть соблазн сразу начать думать про кнопки и стейт, но помним что, калькулятор джун напишет за двадцать минут. Мы же решаем инженерную задачау про то, что мы делаем не страницу, а виджет внутри чужой страницы, и живём по её правилам.

Первое, что стоит спросить у интервьюера - а какой процент людей вообще кликает по этому блоку. Вопрос наверное покажется тупым сначала, а на самом деле он решает всю архитектуру, и я к нему вернусь. Заодно уточняем, что считаем (обычный калькулятор или инженерный, в целом это пригодится для согласования контракта запроса), сколько ещё блоков на выдаче и какой у нас бюджет по размеру бандла.

Дальше поток простой. Бэк поиска понимает, что запрос - это выражение, парсит его и считает на сервере, отдаёт готовый HTML с уже проставленным ответом. Юзер видит «4» до того, как загрузился хоть один килобайт нашего JS. Вот, собственно, ради этого здесь и нужен SSR. Потом виджет гидрируется и становится кликабельным, и с этого момента все вычисления живут на клиенте - бегать на сервер за каждым нажатием кнопки нельзя, это верный способ завалить секцию.

Состояние приезжает с сервера и обязательно сериализуется в разметку, а не пересчитывается заново на клиенте, иначе поймаешь hydration mismatch и блок мигнёт при перерисовке. После гидрации стейт полностью локальный, виджет автономен. Контракт с бэком выдачи выглядит примерно как выражение, его нормализованный вид и результат, причём результат передаём строкой, а не числом - иначе можем потерять точность. И ошибки проговариваем отдельно: невалидное выражение, деление на ноль и переполнение это три разных состояния, а не одно «что-то пошло не так».

Теперь возвращаемся к тому вопросу про клики. Ответ на него такой: подавляющее большинство вбили «2+2», увидели «4» и ушли, они никогда не нажмут ни одной кнопки. Так зачем мы им грузим и гидрируем интерактивный калькулятор? Гидрируем лениво, по первому взаимодействию - клику, наведению. До этого на странице лежит статичный HTML, который стоит ноль. Если это сказать на собесе, то это большой плюсик для тебя, ответ явно не джуна.

Дальше добираем очки от интервьюера. Гидрируем независимо от остальной выдачи, чтобы наш виджет не утащил за собой SERP. Никакого eval ни на сервере, ни на клиенте - выражение пришло от пользователя, это недоверенный ввод, нужен нормальный парсер. Про eval интервьюер спросит почти наверняка, а если не спросит, скажи сам, +реп. Результат детерминирован, «2+2» всегда даёт «4», значит блок прекрасно кэшируется. Ну и резервируем высоту блока, чтобы выдача не прыгала, делаем настоящие кнопки вместо дивов с onclick и вешаем aria-live на результат, чтобы скринридер его озвучил. Сразу видно, что человек думает о доступности, тоже +реп гарантирован.

Если коротко, проверяют здесь одно: понимаешь ли ты разницу между «отрендерить» и «сделать интерактивным», и умеешь ли не платить за интерактивность там, где она девяноста пяти процентам людей не нужна.

Подписывайтесь на канал и вступайте в чатик, товарищи, так вы не пропустите новый контент!

Подписаться: @codeof_art