Недавно в очередной раз смотрел на код моего блога на Gatsby. Во время просмотра поймал себя на мысли о том, что генерация типов не такая уж и плохая вещь (там она используется для graphql). А даже может и лучше, чем написание каких-то сомнительно сложных типов.

“На бумаге” это может выглядеть не так круто. Но на самом деле это намного более практичный подход. TS проекты размером в 500к+ строк и так компилятся не быстро. Не хватает добавить туда еще и инструмент, который сам подхватывает типы на основе сложной логики.

В первый раз с подобными проблемами я столкнулся, когда мы писали админку на Mobx-State-Tree. Инструмент крутой (кроме размера бандла), но авто-подхват типов очень сильно портит всю картину. На проекте примерно в 50к строк очень часто крашился TS Language Server. Да, некоторые вещи мы сами немного не так написали. Но искать причину и тратить на это время было не особо приятно.

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

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

Меня просили видео как-то об этом сделать, давайте пока с поста начнем))).

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

Чаще всего запросы выглядят так, что “вызывается функция X, нужно чтобы было Y, а получается Z”. Если у вас такое понимание проблемы — то найти причину будет не просто.

Нужно полностью понимать, почему все работает именно так. Где вызывается функция X? Почему в итоге получается результат Z, а не Y? Какие именно модули относятся к проблеме. Однако обычно если дойти до таких деталей — то уже помощь других вряд ли понадобиться.

Не зря ведь в опен сорс проектах просят предоставить “minimal reproducible example”. Часто когда его делаешь — то понимаешь, что проблема где-то в твоей бизнес логике.

Также для локализации проблемы бывает полезно закомментировать не связанный по вашему мнению функционал. Убрать ненужные стейты/запросы, или же подставить туда какие-то моковые данные. Это может помочь избежать лишних действий в вашем коде и упросить дебаггинг. А может даже случится так, что ошибка находится как раз в той части, которую вы считали не относящейся к данной проблеме.

Еще один полезный хак, который я постоянно использую для локализации проблемы — это использование console.error, вместо console.log. Нужно это в тех случаях, когда у вас есть какая-то функция, которая используется во многих местах в вашем приложении. В таких случаях сложно бывает понять, где именно она вызывается с неправильными параметрами.

Тут как раз console.error и приходит на помощь. Вы его ставите внутри самой функции, и уже по stack trace смотрите, где именно был произведен неправильный вызов.

Если у вас тоже есть какие-то другие полезные фишки для дебаггинга — буду рад услышать в комментариях.

Очень классные улучшения по вкладке network доезжают в Chrome 117. Да и в целом на этот раз удивлен количеством изменений.

Самая большая фича — это локальный override запросов. Будет супер полезно для тестирования различных ответов от бекенда (ошибки, разные форматы и тд). Тестировщики думаю тоже будут рады данной фиче.

Также из мелочей порадовало то, что теперь ошибки, связанные с подгрузкой source map, не валятся в консоль. А то порой на проектах свои логи искать не возможно из-за этих ворнингов.

Про эти и другие фичи можно почитать по ссылке ниже:
https://developer.chrome.com/blog/new-in-devtools-117/

Довольно много мне приходилось работать с большими списками/таблицами. Поэтому тема виртуализации стороной меня не обошла.

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

Поэтому я решил записать серию уроков (пока планируется 4 штуки), где мы будем разрабатывать наше собственное решение для виртуализации.

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

Оставляйте лайки, комментарии и делитесь видео с друзьями для более быстрого продвижения канала.

P.S. Вчера поста не было, видос на этой неделе выходит только один. Записываю себе все, для будущих розыгрышей.

https://youtu.be/o4MWXQli4iI

Наткнулся на две статьи от Dropbox об их переездах на новый стек для веба и смену своего велосипеда на Rollup.

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

Статья про переезд на новый стек — https://dropbox.tech/frontend/edison-webserver-a-faster-more-powerful-dropbox-on-the-web
Статья про переезд на Rollup — https://dropbox.tech/frontend/how-we-reduced-the-size-of-our-javascript-bundles-by-33-percent

Вроде где-то упоминал уже в видео, но все равно иногда получаю вопросы касательно типизации setTimeout.

Если у вас в проекте установлены @types/node, тогда при использовании setTimeout возвращаемое из него значение будет не number, а NodeJS.Timeout:

/// <reference types="node" />
let timeoutId = setTimeout(() => {});
type Test = typeof timeoutId; // NodeJS.Timer

Это может за собой повлечь ошибки во время компиляции, если вы предполагали, что timeoutId будет number.

Проблема тут заключается в том, что в node setTimeout возвращает объект с различными свойствами и методами (ref, unref, close и тд). Поэтому типизация @types/node описывает их через глобальную типизацию. Все это ведет к тому, что глобальный setTimeout тоже берет типизацию из ноды. Хотя ваш код может никогда там не запускаться.

Решений здесь 2 — использовать window.setTimeout, чтобы ссылаться именно на браузерную типизацию, либо же динамически получить тип для id таймаута.

// решение 1
let timeoutId = window.setTimeout(() => {});
type Test = typeof timeoutId; // number

// решение 2
type TimeoutId = ReturnType<typeof setTimeout>
let timeoutId: TimeoutId  = setTimeout(() => {});
type Test = typeof timeoutId; // NodeJS.Timer

Во втором решении тип TimeoutId будет меняться на основе того, какая типизация подключена у нас в проекте (на сколько я знаю в Deno тоже setTimeout возвращает немного другую структуру).

Подробнее примеры можно посмотреть вот тут — https://tsplay.dev/N7VqBw

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

Код первый раз на запись конечно же не пишу. Иначе на это смотреть было бы далеко не так интересно. Но и с экрана не списываю. Поэтому за видос выходит 2-4 бага.

Обычно вне записи довожу решение до ума, и уже на записи пишу все по памяти. Некоторые вещи получаются чуть по другому. Где-то кажется, что можно по лучше назвать переменную, где-то свои баги замечаю и тд.

Ну и также часть вырезается/удаляется во время записи и монтажа. Чтобы продолжительность была более менее адекватной.

Да и в целом думаю большинство людей (если не все), кто делает обучающие видео, активно готовятся перед записью. Иначе либо качество будет хромать, либо на перезаписи и монтаж придется потратить намного больше времени.

Поэтому не стоит сравнивать спокойный режим разработки с написанием кода на видео. Местами тупить по минут 30-40 — нормальное дело. Ну и смотреть на похожие решение и искать ответы в гугл тоже).

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

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

Даже если посмотреть на какую-нибудь библиотеку. Есть большая разница между умением использовать библиотеку и понимаем библиотеки. Под “пониманием” я не подразумеваю полное знание исходников. Но примерное представление того, как все работает, почему это решение было создано и какие есть альтернативы, нужно иметь.

То же самое касается и проектов. Иногда может казаться, что вы почти доделали проект, разобрались в основных темах, и заканчивать его не нужно. Однако часто последние 5-10% могут вызвать очень много трудностей.

У джунов с проектами в портфолио тоже всегда такая проблема. Есть 5-10 проектов, каждый из которых чут-чуть не доделан. Где-то деплоя нету, где-то код с багами, где-то даже prettier не поставили (не надо так делать). Хотя если сделать 1 хороший пример вашей работы — этого будет более чем достаточно и знаний от всего этого на выходе было бы больше.

Да и по жизни я заметил, что прогресс идет быстрее всего, когда у вас есть одна основная область, где вы фокусируетесь и доводите все начатое до конца, а все остальное отходит на второй план.

Продолжаем нашу серию уроков по виртуализации виртуальному скроллу. В данном ролике будем добавлять возможность рендерить элементы с разной высотой.

Оставляйте лайки и комментарии, для более быстрого продвижения видео.

https://youtu.be/oqgTewKOLlY

Простая и наглядная статья о том, как concurrent mode (тут в частности рассматривается только startTransition) помогает избежать долгих рендеров.

Рассматривается, как именно работает данная фича и в каких случаях она не может помочь избежать лагов.

Если еще не погружались в эту тему — то будет очень полезно:
https://andreigatej.dev/blog/the-underlying-mechanisms-of-reacts-concurrent-mode/

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

Оставляйте лайки и комментарии, для более быстрого продвижения видео. Приятного просмотра!

https://youtu.be/zu5A9ymvs9g

По показателям метрик последние 2 видоса по виртуальному скроллу зашли совсем плохо. Был бы рад, если смогли поделиться своим фидбэком. Смотрели ли какую-то из частей. Если да, то что не понравилось? Если нет, то почему? В общем, любой вброс был бы полезен) Давайте попробуем пообщаться в комментариях.

Немного не стандартное применение, которое я нашел для хука useInsertionEffect (как раз во время подготовки серии видео по виртуальному скроллу):

function useLatest(value) {
    const valueRef = useRef(value);

    // тут вместо useLayoutEffect используем useInsertionEffect
    useInsertionEffect(() => {
        valueRef.current = value;
    }, [value])

    return valueRef;
}

Полезно в тех случаях, когда вы хотите использовать "latest" данные внутри callback ref'ов. Так как callback ref’ы вызываются перед тем, как отрабатывает useLayoutEffect. Вот пример:

const latestState = useLatest({ stateA, stateB });

const cbRef = useCallback(() => {
    const {stateA, stateB} = latestState.current;
    // ...
}, [latestState])

return <div ref={cbRef}>{...}</div>

Если интересна данная тема - дайте знать, могу разобрать подробнее в отдельном видео.

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

И несмотря на то, что причины сами по себе хорошие, я бы предпочел формулировать эти причины немного по другому. Особенно если у вас уже есть несколько лет опыта.

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

По крайней мере у меня и моих знакомых были такие случаи. Особенно при общении с HR.

Как пример, можно сказать что-то такое: «уже давно на текущем проекте ничего интересного не происходит, решил посмотреть, что есть интересного на рынке». Либо «интересно попробовать себя в новой индустрии/команде».

В общем, я думаю идея понятна. Главное, чтобы первое впечатление о вас сразу же не испортилось).

Наткнулся тут на новость о том, что Vercel теперь становится hosting-партнером astro. Соответственно теперь будут различные плюшки, если вы будете деплоить свое asto приложение на Vercel (оптимизация картинок, edge и тд)

Знаю, что многие хейтят Vercel с технической точки зрения, но мне с другой стороны кажется очень умным то, как они ведут свой бизнес). По сути есть различные фичи, которые помогают твоему приложению работать быстрее (сам много не тестил, но людям нравится). Есть тесная интеграция с твоим фреймворками. По итогу ты можешь и в другое место деплоиться, никто не привязывает тебя, но там уже плюшек всех не будет. Даже интересно стало, кто за этим стоит. Так как обычно на видосах/конфах видишь только технарей.

Также из интересного, проект Rome (один инструмент для форматирования, линтинга, сборки и тд), которым занимался создатель Babel, перестал поддерживаться. Но по итогу мейнтейнеры проекта решили сделать fork и продолжить разработку инструмента. Название оставили похожее — Biome.

Вообще сама идея у проекта была прикольная. Есть один инструмент, который может делать сразу все нужные операции над вашим кодом, один раз построив AST (давно читал о нем, могу ошибаться). Но, как видите, он не нашел успеха. Интересно, что будет с его предшественником.

Ссылки на статьи:
https://astro.build/blog/vercel-official-hosting-partner/
https://biomejs.dev/blog/annoucing-biome

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

1) Всегда когда сам ищешь заказ, кажется, что нужен уже какой-то опыт на площадке. Хотя, когда я подбирал себе исполнителя, понял, что этот фактор не так важен (для меня), если всё остальное устраивает. Кажется, что хорошие примеры работ в 100 раз важнее, чем 100500 выполненных заказов. Поэтому я бы не советовал идти и супер занижать себе цену, для того, чтобы “набить опыт” (меня кстати такие люди совсем смутили, готовы делать недельную работу за 1000 рублей).

Ну и по поводу примеров работ, был удивлен, что реально мало у кого было что-то похожее на реальный проект. Даже у тех, кто уже выполнил много заказов)

2) Самый важный фактор, по которому я искал человека — это опыт решения тех же проблем. Мне нужен был человек, который может показать мне, как нужно действовать в моей ситуации. Может где-то даст какие-то советы на основе ТЗ, скажет как лучше делать. А в итоге все просто просили точнее расписать каждую деталь.

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

Мне нужна была голова, а все предлагали руки)))

3) Сам часто слышал, что нужно подробно всё расписывать, когда откликаешься на заказ/вакансию. Когда оказался с другой стороны для себя понял, что толку от всего этого почти нет. Если это только не какой-то полезный совет/замечание по ТЗ. Опять же, все люди разные, по этому тестируйте. Но тонна текста об опыте, кажется, сильно не дает плюсов.

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

Лично для себя мне понятно стало, почему я с бирж не мог раньше даже одного заказа получить. Так как от всей толпы откликающихся я ничем не отличался. Писал все те же типовые ответы. А там уже игра идет “кто ниже цену предложит” или “у кого больше заказов высоленных”.

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

Для тех, кто не знаком с useInsertionEffect, хотел бы быстро рассказать о том, как он помогает CSS-in-JS библиотекам эффективнее встраивать свои стили.

Но давайте в начале немного погрузимся в саму проблему и поймем, почему не подходит тот же хук useLayoutEffect?

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

Однако проблема useLayoutEffect в том, что он ещё и активно используется для замера DOM элементов. То есть это может привести к череде "чтение => добавление стилей => чтение", что сильно будет бить по перформансу. Браузеру несколько раз придётся пересчитывать стили/размеры элементов документа (операция, как понимаете, не дешевая). Также добавленные стили в теории могут поменять размер только что замеренного элемента, что в итоге приведет к неправильной работе вашего компонента.

Также у нас есть callback рефы, которые вызываются до layout effect'ов и тоже могут читать размеры из документа.

Получается, нам каким-то образом нужно отделять стадию вставки стилей в DOM и вызывать её до callback рефов и layout effect'ов. Тут как раз на помощь и приходит useInsertionEffect. Дока говорит нам о том, что при вызове insertion effect'ов у нас даже нет гарантии того, что DOM ноды были созданы. А значения рефам точно ещё не были присвоены.

По моим экспериментам, при первой загрузке страницы у нас useInsertionEffect вызывается до того, как создаются DOM ноды. При обновлении стейта - после обновления DOM.

Вышло новое видео, где я рассказываю о нестандартном применении, которое я нашел для хука useInsertionEffect (обновление рефов). Разберем, почему он хорошо подходит для этой задачи и в целом поговорим о том, для чего изначально он был добавлен в React 18.

Оставляйте лайки и фидбэк в комментариях, для более лучшего продвижения видео. Приятного просмотра!

https://youtu.be/ILg1zhl92AI