🚧 Почему виртуальный скролл ломается на больших данных

Сегодня хочу рассказать вам вот об этой статье How to Implement Virtual Scrolling Beyond the Browser's Limit.

Когда мы говорим, что нужно оптимизировать рендеринг большого количества элементов в браузере — чаще всего речь идёт о виртуальном скроллинге.

Обычно он реализуется так:
- есть элемент, назовём его viewport,
- внутри — контейнер content, в котором находится список всех элементов,
- этому контейнеру задаётся высота по формуле: высота одного элемента × общее количество элементов,
- при этом рендерятся только те элементы, которые попадают во viewport, а их позиция задаётся через transform: translateY(...).

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

Когда мы задаём общую высоту контента, она может оказаться больше, чем максимально поддерживаемое значение в браузере. Я измерил локально и получил такие значения:
- Safari: 33,554,428px
- Chrome: 16,777,200px
- Firefox: после определённого значения значение сбрасывается в 0

Ограничения можете проверить сами.
👉 Здесь накидал небольшую демку.

Из-за этого нельзя доскроллить до самого конца списка — высота просто "обрезается".

Примеры:

<!-- Safari: высота обрежется до 33,554,428px -->
<div style="height: 9999999999999px;"></div>

<!-- Даже без прямого указания общей высоты -->
<!-- В сумме 40,000,000px, но всё равно обрежется -->
<div>
  <div style="height: 20000000px"></div>
  <div style="height: 20000000px"></div>
</div>

На работе мне нужно было реализовать JsonViewer, который умеет отображать огромные JSON-файлы.

Я использовал TanStack Virtual для виртуального скроллинга, но столкнулся с описанной выше проблемой — реальная высота контента была в два раза больше, чем поддерживают браузеры. Позже нашел, что в их репозитории есть ишью по этому поводу.

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

Выглядит это примерно так:

const ITEM_HEIGHT = 30;

// Генерируем список из 3 миллионов элементов
const items = Array.from({ length: 3000000 }, (_, i) => `Item ${i}`);

// 3,000,000 × 30px = 90,000,000px (> лимита браузера)
const totalHeight = ITEM_HEIGHT * items.length;
const viewportSize = 300;

export default function App() {
  return (
    <ScrollPane contentSize={totalHeight} viewportSize={viewportSize}>
      {(scrollPosition) => {
        // Вычисляем, какие элементы нужно отрендерить
        const startIndex = Math.floor(scrollPosition / ITEM_HEIGHT);
        const endIndex = Math.min(
          Math.ceil((scrollPosition + viewportSize) / ITEM_HEIGHT) + 1,
          items.length
        );
        const visibleItems = items.slice(startIndex, endIndex);

        // Смещение первого видимого элемента
        const startPosition = startIndex * ITEM_HEIGHT;

        return (
          <div
            style={{
              position: 'absolute',
              top: startPosition - scrollPosition,
            }}
          >
            {visibleItems.map((item) => (
              <div key={item} style={{ height: ITEM_HEIGHT }}>
                {item}
              </div>
            ))}
          </div>
        );
      }}
    </ScrollPane>
  );
}

Демку, где рендерятся 3 миллиона элементов, можно посмотреть здесь.
Подробнее это всё разбирается в статье.

#JavaScript #Performance #Browser

Модуль 1 - Работа с командой - аудит и командообразование (часть 1)

Три недели назад закончилась первая трёхдневка "Модуль 1. Работа с командой - аудит и командообразование" моего обучения в Стартоплане, но забегался и руки написать пост дошли лишь сейчас.

Сегодня поговорим о том, чем команда отличается от не-команды.


Команда 🆚 Не-команда

Возможно, это не очевидно, но не всегда люди, работающие вместе и решающие общую задачу, являются "настоящей" командой. Тема большая, но меня как начинающего и неопытного руководителя «зацепило» два момента:

Взаимодействие и обратная связь

✅ В команде — все взаимодействуют друг с другом, все дают друг другу конструктивную обратную связь. Если критикуют — то работу, а не человека и его личные качества.
🟥 В не-команде — всё взаимодействие идёт через руководителя или неадресно.

Логика примерно такая: «Ну, с ним (руководителем) я уже привык взаимодействовать, а коллегам писать влом, некомфортно, и вообще вот тот чувак меня раздражает, я тимлиду скажу, а он пусть сам со всем разберётся».

Или вот ещё: как часто вы видите похожие сообщения — «Коллеги, нужно сделать вот это…». То есть коллега пишет сообщение в общий чат «в никуда» и считает, что «я написал, а там как хотите». Отклика на сообщение не ждёт — если ответа нет, ну и ладно. Знакомо такое? Мне да. 😅


Командная цель

✅ В команде — каждый воспринимает командную цель как свою собственную.
🟥 В не-команде — все сконцентрированы только на том, чтобы закрыть свои задачи.

Правда, чтобы этого достичь, руководитель должен поработать с «интернализацией цели», чтобы коллеги действительно воспринимали командную цель как свою.

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

Вообще, на курсе обсуждали, что для интернализации цели часто нужна outcome interdependence — взаимозависимость членов команды.

Например:
- Если команда в целом работала хорошо — все получают премию.
- Если нет — то на нет и суда нет, как говорится.

Иначе как ты интернализируешь цель «красить кнопочки хорошо, а плохо не красить» для фронтендеров? 😄


Номинальная команда

Если всё управление происходит выделенным человеком, а все остальные занимаются только своим делом, и остальное их не интересует, то команду можно назвать «номинальной».

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

В один пост всё не влезет, поэтому в следующий раз расскажу про:
- Модель Такмана
- Виды организационных структур. У нас в компании как раз сейчас меняется орг структура, из-за чего я и стал Тимлидом.
- Небольшой отзыв в целом на модуль

#стратоплан

Модуль 1 - Работа с командой - аудит и командообразование (часть 2)

Итак, ненадолго вернёмся к моему обучению в Стратоплане. Я коротко упомяну то, что не вместилось в первую часть.


1️⃣ Модель Такмана

Это одна из моделей, описанных на основе анализа и статистики разных команд, которая описывает стадии, через которые проходит коллектив, прежде чем стать настоящей командой. Это оказалось очень актуально для меня, так как наша команда сформировалась совсем недавно.

Основные стадии по Такману:

😇 Формирование (Forming)
Люди только познакомились. Все вежливы, стараются понравиться, избегают острых углов. Ждут указаний от лидера, работают каждый по своей задаче.

😤 Конфликт (Storming)
Начинают проявляться настоящие характеры. Возникают конфликты, разочарования и спады мотивации. Часто звучит: «Я думал, будет по-другому».

🤝 Нормализация (Norming)
Появляется доверие. Люди договариваются о правилах, открыто просят помощи, привыкают друг к другу. Работать становится легче и спокойнее.

🚀 Продуктивная работа (Performing)
Команда работает как единое целое. Участники инициативны, подстраховывают друг друга, всё идёт чётко и слаженно.

🧳 Расставание (Adjourning)
Проект завершается. Люди делятся воспоминаниями, чуть грустят, постепенно переключаются на новые задачи.

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

---

2️⃣ Виды организационных структур

Немного про организационные структуры — на примере нашей компании.

Раньше у нас была функциональная модель: отдельные команды разработчиков, тестировщиков, аналитиков. Каждый фокусировался на своей части.

Сейчас переходим к кросс-функциональным командам. В одной команде теперь и разработчики, и QA, и аналитики — вместе делают фичу от начала до конца. Функциональные направления при этом остаются, но больше как «сообщества практики».

Аналогия:
- Функциональная структура — это когда все контроллеры, стили, тесты лежат по отдельным папкам (controllers/, styles/, tests/)
- Кросс-функциональная — всё, что нужно для одной фичи, в одной папке (feature-login/: контроллер, стили, тесты)

Так проще координироваться и быстрее двигаться.

---

3️⃣ Короткий итог

- Программа хорошо структурирована, поэтому было реально полезно
- Можно задать собственные вопросы в чате и получить ответы от преподавателей
- Есть практика в группах, но хотелось бы больше разборов собственных кейсов из жизни или более реалистичных примеров
- Информации реально много, но не совсем понятно, с чего начать её применять. Очень короткая выжимка со списком шагов по улучшению команды была бы невероятно полезна в нашем быстротекущем мире

#стратоплан

🔇 Митинги без шума

Пару месяцев назад я созванивался с коллегами из индийского офиса — и каждый раз это было похоже не на рабочую встречу, а на трансляцию политических дебатов. На фоне — шум, гул, кто-то спорит, кто-то смеётся.

Потом стало заметно тише. Я подумал, неужели у них в офисе стало настолько тише, но нет. Мне рассказали, что они просто включили Voice Isolation в Teams.

Как это работает: вы читаете небольшой текст, Teams создаёт ваш голосовой профиль, и с этого момента во время звонков AI приглушает все посторонние звуки — собеседники слышат только ваш голос.

Так что, если пользуетесь Teams — обязательно настройте.

А чем вы пользуетесь на работе?
- Telegram
- Slack
- Teams
- WhatsUp
- Skype 😳

Постановка задач, фидбек и делегирование

Второй месяц в Стратоплане был посвящен постановке задач, фидбеку и делегированию.

🏞️ Постановка задач и причем тут картинки

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

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

Например, сравните:
- «Хочу, чтобы вы активнее участвовали в планировании спринта.»
- «Тестировщики — приносите на планирование список задач по прошлому релизу, чтобы мы выбрали самые важные. Разработчики — делитесь своими оценками по задаче, обсуждайте, где могут быть подводные камни, и что могут затронуть изменения. Это поможет точнее оценить задачи и лучше подготовиться к тестированию.»

Какой вариант рисует в вашей голове более чёткую картинку?

🗣️ Фидбек

Начнём с метафоры «принцип альпинистского крюка»: если ты как альпинист хочешь забраться выше, сначала тебе нужно вбить крепко крюк, зацепиться, прицепить страховку и когда ты чувствуешь себя уверенно — можешь лезть выше.

Это я к чему, есть 2 типа фидбека:
- Поддерживающий
- Корректирующий

Когда мы даём сотруднику поддерживающий фидбек — забиваем тот самый крюк, чтобы он чувствовал себя уверенно. Мы рассказываем, что у него получается хорошо (на конкретных примерах), чтобы он продолжал это делать. И в итоге он будет это делать чаще и более осознанно. Поэтому не забывайте лайкать посты, которые вам нравятся, чтобы я понимал, что всё делаю правильно 😄

Например:

«На вчерашнем планировании ты указал на риски и предложил решение — это помогло точнее оценить задачу и избежать переработок.»

Корректирующий — мы объясняем, к чему привело определённое поведение, и что следовало бы скорректировать.

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

💡 Поддерживающего фидбека должно быть больше чем корректирующего, чтобы человек чувствовал себя увереннее и мог морально опереться на свои сильные стороны, чтобы исправить то, что пока не получается.

Жаль, что это никогда не прочитает мой инструктор по вождению, который резко жал на тормоз, вместо того, чтобы объяснить, что я делаю не так 😅.

Ещё одна фраза из курса, которая особенно понравилась: «Похвала без фидбека — сахар без чая».

🤝 Делегирование

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

Чтобы понять, что делегировать — выпишите подробно, чем вы занимаетесь ежедневно и оставьте себе те 20% работы, которые приносят 80% пользы компании.

И тут есть неочевидные моменты. Например, если вы ответственны за планирование спринта — это не значит, что вы должны делать всё сами:
- можете делегировать кому-то делать заметки
- оценку задач делаете совместно с другими разработчиками
- а приносить список косяков из прошлого спринта — делегируете тестировщикам


Поэтому после того, как вы составили список — попробуйте раздробить задачи на более мелкие, возможно вы сможете делегировать, если не всю задачу — то какую-то её часть.

И ещё пара моментов:
- Если делегируем ответственность — нужно давать необходимые полномочия
- Редко бывает, что можно делегировать что-то и забыть об этом. Подбираем уровни контроля в зависимости от опыта исполнителя.


📝 Отзыв

Этот модуль мне понравился больше предыдущего. Тут было меньше теории и гораздо больше практики. Было много полезных аналогий и ролевых игр, где тренер наглядно показывал, как вести диалог с руководителем и давать фидбек.

❤️ — оставляем подкрепляющий фидбек
🔥 — было полезно
😎 — я уже всё это знаю

#стратоплан

На минувших выходных в Стратоплане обсуждали специфичные фразы и «обычаи», которые употребляются только внутри определённой команды.

Решил поделиться некоторыми из них:
- Православный релиз — когда тесты не прошли, и релизишь с божьей помощью.
- Гипс — когда накостылил в реализации, времени переделывать нет, «загипсовал» и релизишь.

Актуально для офисных работников:
- Тебе на стол кладут краба 🦀, если ты положил прод. Краб — такой «символ» упавшего прода.
- Последнему человеку, который запушил костыль, ставят на стол статуэтку золотого костыля 🏆.

У нас, например, на одном из созвонов все молчат, пока не подключится американец и не спросит: «Is anyone talking?». Однажды он подключился на созвон, камеры у всех были выключены, он не мог понять, говорит ли кто-то, и спросил: «Is anyone talking?». Так и появился этот «обычай».

А у вас в команде есть похожие фразы или обычаи?

#weekphrase #стратоплан

🧠 Банк памяти

Я чувствую, что еле поспеваю за развитием ИИ, но потихоньку втягиваюсь и разбираюсь, как ускорить разработку. Сейчас разбираюсь с мемори бэнк и понял, что ничего нового в этом подходе нет.

Приведу простой пример.

Допустим, какая-то кнопка в новой версии приложения глючит — то работает, то нет, и только в каких-то странных ситуациях. Что я делаю? Завожу страничку в Obsidian и начинаю расследование.

Я записываю:
- когда именно кнопка отказывается работать
- поведение в старой версии
- копаюсь в запросах во вкладке Network
- и так далее, короче записываю, всё, что выяснил.

Потом приходит менеджер и говорит «Сань, сколько времени займет эта задача?». И тут я меняю «контекст» и разбираюсь в другой задаче.

Спустя какое-то время, я возвращаюсь к проблеме с кнопкой и именно этот конспект помогает мне загрузить весь «контекст» задачи назад в мою голову.

Вот так и работает мемори бэнк у ИИ-агентов. Это обычный Markdown-файл, где собрана вся нужная информация о твоём коде — например, требования к фиче. Без него ИИ может забыть какие-то детали, если начнёшь новый чат или контекст переполнится.

В теории всё понятно, но вопрос как внедрить его в огромный существующий проект. Если у вас есть такой опыт, расскажите 🙏.

#Ai

Я как-то упустил насколько быстро сейчас развивается CSS. Кажется, что через несколько лет препроцессоры и другие решения будут не особо то и нужны.

- CSS переменные у нас уже есть давным давно
- поддержка 95%
- Вместо БЭМА и CSS модулей сможем использовать @scope
- поддержка 82%
- Можем сократить количество !important при переопределении стилей, просто помещаем стили внутрь разных каскадных слоёв с помощью @layer.
- поддержка 93%
- Смешиваем цвета прямо в CSS
- поддержка 91.5%

color-mix(in srgb, var(--c), white var(--pct))

- Заменяем медиа выражения на if-ы
- поддержка 64%

color: if(style(--theme: dark): white;
 style(--theme: light): black;
 else: black);

- Долой миксины, да здравствуют нативные кастомные функции
- поддержка 0.04% — свежачок 🥒

/* Функция для смешивания цвета с белым */
@function --tint(--c, --pct) {
  result: color-mix(in srgb, var(--c), white var(--pct));
}

Наверняка ещё что-то упустил, если что — подскажите 🙏.
Проверить, что все эти функции действиетльно работают (в хроме) можно 👉 вот в этой демке — просто загляните в исходники.

Подробнее здесь:
- @layer - Управляем каскадными слоями своими руками
- Условные операторы CSS с новой функцией if()
- Знакомимся с @scope в CSS
- Custom CSS Functions in the Browser

#css