Ayub Begimkulov - уроки по JS

Стрим начнется с минуты на минуту. Подключайтесь, будем продолжать наш вчерашний проект. https://youtube.com/live/bp903YS4Bxk?feature=share

Начинаем через 15 минут. У кого есть время — заходите. https://www.youtube.com/live/afWcwr9cJd0?si=pfU_RVTx75anjy2D

Для тех, кто тоже не любит скачивать cli различных библиотек глобально, нашел вариант, как можно этого избежать:

npx -p {package_name} {cli_command}

Вот пример со стартом ангуляр проекта, без скачивая @angular/cli:

// вот это
npx -p @angular/cli ng new angular-app

// вместо
npm i -g @angular/cli
ng new angular-app

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

Для одного из проектов искал инструмент, который мог бы найти все не используемые экспорты (eslint такого оказывается не умеет). По началу казалось, что почти любой инструмент справится. Однако, как оказалось, многие решения замечали далеко не все проблемные места (может тут какая-то специфика проекта, хотя ничего особенного вроде там нет). В итоге после проб разных инструментов, остановился на 2-х — ts-prune и ts-unused-export. Первый уже активно не поддерживается, хотя работает в целом хорошо. Ко второму претензий нет. Даже обертка для работы в виде eslint плагина есть. Если вам нужна проверка на неиспользуемые экспорты в проекте — рекомендую попробовать. https://github.com/pzavolinsky/ts-unused-exports

Пару апдейтов по ближайшему контенту на канале. Готовлю плейлист по погружению в детали React. Хочется разобрать все базовые вещи, в которых у многих я вижу пробелы (наверное что-то похожее на разборы по JSX и синтетической системе ивентов). Опыт менторинга и комменты под плейлистом по хукам показали, что те моменты, которые я предполагал, что уже все знают, оказались понятными далеко не для всех. Думаю будет полезно и тем, кто раньше смотрел. Также тех, кто только пришел на канал можно будет на этот плейлист отправлять, перед видосами по хукам. Так вот, по этому поводу хотел спросить, что именно вам было бы интересно, чтобы я разобрал в этой серии видео? Наверняка я про какие-то темы забыл. Пишите все идеи в комменты, обязательно все прочитаю и учту. Также, помимо подготовки плейлиста скопилась другая работа по проектам, поэтому давайте на этой неделе вместо видео проведем 2 стрима. Проходить они будут в эти субботу и воскресенье в 12:00 по мск. Если хотите задать какие-то вопросы — буду ждать. В плане кода собираюсь начать пилить проект на Next + React Server Components. Хочется детальнее погрузиться в тему и в дальнейшем сделать больше видео на эту тему (разбор опыта, какие-то паттерны, как работает под капотом).

Периодически получаю вопросы о том, откуда я беру идеи для видео и постов. Нет ли ощущения, что скоро уже не останется тем. Данный вопрос мне показался интересным, так как раньше сам удивлялся, как у людей получается постоянно что-то придумывать. Особенно когда смотрел на каких-то ютуберов, которые снимают по 5-10 лет видео в одной нише. Да и в целом придумать тему для видео, статьи или проекта раньше было очень сложно. Порой бывало сидел 30-40 минут у ноута и просто думал. Улучшить данную ситуацию мне помогли 2 вещи: 1) Вести список, куда я записываю свои идеи. Уделять ему минут 5-10 в день. Где вы будете вести этот список — не важно. Главное, чтобы всегда был под рукой. Мне в этом плане дефолтное приложение заметок нравится на Маке. В ноушен уже потом переношу. После того, как начинаешь вести список понимаешь, что идеи какие-то всегда есть, просто ты их забываешь. А когда они нужны — то уже ничего не вспомнишь). 2) Явная цель, для которой нужно придумывать идеи. История с двумя видео в неделю и одним постом в день в этом году сосем по другому открыла глаза на вопрос придумывания идей. Раньше у меня не было каких-то четких сроков, поэтому как-то фокуса у меня не было на том, чтобы замечать идеи вокруг. Хотя на самом деле решая даже банальные ежедневные задачи или проводя ревью можно найти очень интересные моменты, которые могут быть полезны и другим. Когда же появились сжатие сроки и какое-то “наказание” за их нарушение, то мозг начал постоянно фокусироваться на этой теме. Например, отвечая даже на вопросы в комментариях я начал задумываться о том, есть ли у этого вопроса какое-то более глубинное происхождение, которое можно было бы раскрыть в отдельном посте или видео. Либо же смотря на код какой-то библиотеки приходят идеи, чем интересным от туда можно было бы поделиться. В общем, все просто и банально. На чем мысли фокусируешь — о том идеи и будут приходить, а дальше их просто не забывать надо. Главное просто начать как-то. Надеюсь кому-то будет полезно.

Подвел итоги розыгрыша. Удача подвернулась на этот раз к @stake44 @KasparovN @foydali_fkr @dragonite24 @tokarskyy. Давайте поздравим победителей!

Наконец выходит последнее видео по разработке нашего собственного решения для виртуального скролла. Добавим такие фичи, как горизонтальная виртуализация и динамический замер ширины колонок. Также поправим баги из прошлых уроков и сделаем небольшие улучшения по перформансу в конце видео. Те, кто ждал выхода всех частей — можно начинать смотреть плейлист. Также буду рад вашим лайкам, комментариям и рекомендациям коллегам/друзьям, это помогает каналу быстрее развиваться. https://youtu.be/8wWDGwjdbDs

Пост для сбора комментариев на розыгрыш.

Друзья, на этой неделе будет только одно видео. Поэтому давайте проведем розыгрыш по всем «долгам». Накопилось у нас их 5. Для тех, кто не знает, я пообещал выпускать 2 видео в неделю и 1 пост в день. За каждый пропуск розыгрываю 1:1 сессию менторинга или $50. Чтобы участвовать, нужно оставить ровно 1 коммент под следующим постом.

Тут увидел, что Ден Абрамов теперь работает в bluesky (первый раз слышу, говорят, что аналог twitter). Но что мне показалось более интересным, так это их опен сорс приложение на react-native, expo и mobx. Пока кода не так много — разобраться не должно быть сложно. Кто хотел посмотреть на какой-то референс того, как пишут код в реальном мире — думаю пример не плохой. Также можно будет в дальнейшем следить за изменениями в ПР, что тоже бывает полезно. А так, интересно еще насколько переход Дена повлияет на развитие React Native. Так как он над самим реактом до сих пор работает. Вообще помню пару лет назад была новость, что сам фейсбук съезжает с react native, так как он для их приложения не зашел. Я тогда думал, что проекту конец. Но это оказалось не так, он до сих пор активно развивается, что не может не радовать.

Получил вопрос от подписчика о том, почему JSX переданный в children или другие пропсы не будет обновляться при обновлении компонента, в который он передан. Речь идет о таком кейсе:

<Dialog header={<Header />} />

Тут у нас при обновлении компонента Dialog, у компонента Header не будет происходить ререндер. Чтобы ответить на этот вопрос, нам нужно разобрать 2 момента. Во-первых, при обновлении компонента Dialog у нас проп header будет иметь одно и то же значение. То есть он будет иметь ссылку на один и тот же JSX объект (подробнее тему с самим JSX разбирал вот в этом видео). Поведение в целом логичное, так работают все пропсы, но решил все же уделить этому отдельное внимание. Во-вторых, если не меняется ссылка на JSX объект, то ререндера не будет, даже без использования memo:

const Component = () => {
  console.log("render");
  return <div>Random</div>;
};

const componentJSX = <Component />;

const Counter = () => {
  const [count, setCount] = useState(0);
  return (
    <div>
      <div onClick={() => setCount((c) => c + 1)}>{count}</div>
      {componentJSX}
    </div>
  );
};

В примере выше в консоли вы увидите "render" только один раз при первом рендере. Почему? Потому что React в первую очередь проверят, поменялась ли ссылка на JSX объект. Если нет — то и обновлять там нечего. Поэтому рендер не происходит. В случае же если вы напишите <Component /> внутри компонента Counter, то JSX объект описывающий компонент Component будет создаваться при каждом рендере заново, что поведет за собой и дальнейший ререндер данного компонента. Теперь, собирая все вместе я думаю становится понятно, почему переданные в пропсы компоненты не будут обновляться при изменении стейта.

Часто получаю сообщения от подписчиков о том, что после нескольких лет работы, они чувствуют плато в своем развитии. Вроде бы и базовые задачи решать могут, собеседования проходят. Но как дело доходит до чего-то более сложного — долго приходится разбираться, нет уверенности в решении сложных задач, постоянно приходится смотреть решения в интернете и тд. И чаще всего вопрос почему-то один и тот же: “а что можно почитать/посмотреть?”. Тут мне кажется и лежит обычно проблема. Да, читать новый материал полезно. Но кажется после определенного момента это не дает такой сильной пользы. Вроде бы все основные знания уже есть. А что-то более глубокое и сложное не всегда нормально передашь в виде статьи или видео. Например, то же общение между компонентами и поток данных в вашем приложении. Вроде можно показать пару примеров. Но ситуации бывают разные, все не расскажешь. Да и примеры хорошие зачастую составить сложно — либо непонятно и специфично будет, либо слишком просто. Да и в конце концов очередное поглощение материала сильно вперед вас не двинет. Поэтому могу посоветовать 2 вещи: 1) Пробовать решать рабочие задачи разными способами. Для начала можно начать с того, что вы просто выписываете различные варианты решений. Пробуете в голове наложить каждый из них, понять плюсы и минусы. Потом уже выбрать какой-то способ. Можно по началу для практики пробовать выбирать что-то новое для вас. По началу сложно будет придумывать разные варианты. Да и накладывать их на проект и находить плюсы/минусы тоже. Но чем больше будете пробовать — тем лучше будет становиться. Тут также можно пробовать реализовывать идеи из различных статьей/книг/видосов (главное тут держать баланс). Ну и когда есть время — можно пробовать реально реализовывать задачу несколькими способами. 2) Делать сложные задачи вне вашей зоны комфорта. Я чаще всего говорю написать клон библиотеки, которую вы постоянно используете, так как уже и функционал ясен, и в целом понимаете, какие есть детали. Еще большой плюс в том, что можно скопировать тесты и сверять свое решение относительно них. Но можно и что-то другое взять. Главное, чтобы вам было интересно и вы понимали, как работает “бизнес” часть, и думали только о коде. 3) Пробовать разбираться в темах, которые вы не понимаете. Искать ответы на свои вопросы. Лично у меня часто возникают вопросы о том, как работает какой-то инструмент, с которым я работаю. Чаще всего не весь, а какая-то определенная деталь. Либо же почему разработчики пошли на решение Х, вместо У? Какие там есть плюсы/минусы? Несмотря на то, что эти вопросы у меня возникают во время важных задач, когда нельзя отвлекаться, я стараюсь вести список таких вопросов, чтобы потом можно было вернуться и разобрать все недопонимания. Очень часто узнаю что-то новое таким образом. Примерно такой список у меня получился. Если у вас есть свои идеи и советы — делитесь в комментариях.

Давайте сегодня вместо поста попробуем чуть пообщаться. Заходите в голосовой чат и задавайте свои вопросы.

Часто получаю вопросы о том, как можно адекватно оценить свой уровень на рынке. И тут думаю ответ очевидный — просто проходить собесы и смотреть, на какую должность/зп у вас получается пройти. Однако проблема у людей возникает с тем, что на первом этапе при общении с рекрутером у них спрашивают ожидания по ЗП. Получается замкнутый круг. Чтобы узнать уровень — нужно проходить собесы. Чтобы проходить собесы — нужно называть ориентировочную ЗП (соответственно, понимать примерный уровень). Но, большое заблуждение заключается в том, что обязательно сразу же надо отвечать на вопрос о ваших зарплатных ожиданиях. Тут просто рекрутеры хотят сделать свою работу по проще и сразу узнать всю информацию. Я обычно на такие вопросы отвечаю примерно так: “Сейчас рассматриваю очень много разных предложений, везде разные условия, разная команда, продукт, стек, плюшки и тд. Поэтому сложно называть какое-то конкретное число, не узнав все детали. Предпочел бы отложить данный разговор на потом. Если обе стороны все устроит, думаю сможем уже договориться и по компенсации.” Чаще всего этот момент просто пропустят и вернутся к этому вопросу позже. Когда проходил собесы в ОАЭ/Европу, я заметил, что рекрутеры в таких случаях почти всегда сами говорят свою вилку и спрашивают, подходит ли она под ожидания. В России я такого ни разу не встречал, хотя собесов намного больше проходил. Иногда бывает, что рекрутер прямо настаивает на том, чтобы вы назвали сумму — в таких случаях рекомендую называть очень широкую вилку. Верх обязательно должен быть супер высоким. Например, вы идете на мидла и ориентируетесь на ЗП 240-260. В таком случае можно сказать рекрутеру что-то такое: “Сейчас вот общаюсь с разными компаниями. Вилка примерно 240-320, ну и других деталей везде много помимо самой компенсации”. Плюсов тут сразу несколько: 1) Вы не знаете, какой на самом деле бюджет на позицию у компании. Часто бывает, он намного выше, чем ваши ожидания (синдром самозванца есть почти у всех). Однако раз сами попросили — никто геройствовать не будет. Просто сэкономят деньги. Поэтому стоит заложить на такой случай. Если вы хорошо пройдете собес и понравитесь компании — то вам сразу же могут дать ЗП больше, чем ваши изначальные ожидания. 2) Вы оставляете окно для торга. Если назвать конкретное число — то и торговаться будет не удобно. 3) Даже если вы оценили свой уровень правильно (низ вашей вилки). То запас сверху даст психологический эффект. Если говорить простым языком, то когда вы говорите 240-320, то промежуток 240-260 выглядит как адекватное число, даже маленькое. А когда вы говорите просто 240 — то тут уже немного другой эффект получается. Если интересна данная тема, то могу посоветовать вот этот видос и книгу “Никаких компромиссов”, автор Крис Восс (там разные типы переговоров обсуждаются, но про ЗП и работу тоже есть глава). Ну и на конец скажу, что никто вас не заставляет всем этим заниматься. Если хотите — можете сразу называть конкретную сумму. Компании так точно проще будет. Однако если хотите получать максимально хорошую компенсацию — то лучше подходить к общению чуть более тактично.

Вышло новое видео, где я рассказываю о нестандартном применении, которые я нашел для хука useInsertionEffect (обновление рефов). Разберем, почему он хорошо подходит для этой задачи и в целом поговорим о том, для чего изначально он был добавлен в React 18. Оставляйте лайки и фидбэк в комментариях, для более лучшего продвижения видео. Приятного просмотра! https://youtu.be/ILg1zhl92AI

Простая и наглядная статья о том, как можно избежать большого количестве непонятных пропсов в ваших компонентах, передавая JSX разметку внутрь компонента. Примеры сильно упрощены, но думаю суть будет понятна. Единственный момент, которому тут не уделили внимание — это то, что делать если компонент уже написан на стандартных пропсах и хочется переехать на подход с передачей JSX снаружи. Ведь не всегда есть возможность пройтись по всем использованиям и поправить их. Обычно в таких случаях стоит использовать jsdoc тег @deprecated (вот тут о нем писал) для пометки старых пропсов, как не актуальных. Ну и описать там то, на что нужно все это дело менять (пример на скрине). Таким образом в коде новых использований не актуального пропса появляться не будет. Да и по мере изменений в приложении старые места тоже будут исправляться. https://kyleshevlin.com/quit-your-yapping

Для тех, кто не знаком с useInsertionEffect, хотел бы быстро рассказать о том, как он помогает CSS-in-JS библиотекам эффективнее встраивать свои стили. Но давайте в начале немного погрузимся в саму проблему и поймем, почему не подходит тот же хук useLayoutEffect? Вызывается он синхронно, пока браузер ещё не успел обновить экран. Следовательно, встраивание там стилей не приведет к мерцанию экрана. Однако проблема useLayoutEffect в том, что он ещё и активно используется для замера DOM элементов. То есть это может привести к череде "чтение => добавление стилей => чтение", что сильно будет бить по перформансу. Браузеру несколько раз придется пересчитывать стили/размеры элементов документа (операция, как понимаете, не дешевая). Также добавленные стили в теории могут поменять размер только что замеренного элемента, что в итоге приведет к неправильной работе вашего компонента. Также у нас есть callback рефы, которые вызываются до layout effect'ов и тоже могут читать размеры из документа. Получается, нам каким-то образом нужно отделять стадию вставки стилей в DOM и вызывать ее до callback рефов и layout effect'ов. Тут как раз на помощь и приходит useInsertionEffect. Дока говорит нам о том, что при вызове insertion effect'ов у нас даже нет гарантии того, что DOM ноды были созданы. А значения рефам точно ещё не были присвоены. По моим экспериментам, при первой загрузке страницы у нас useInsertionEffect вызывается до того, как создаются DOM ноды. При обновлении стейта - после обновления DOM.

Пару месяцев назад искал себе дизайнера, впервые пришлось оказаться с другой стороны на фриланс бирже. Решил поделиться некоторыми мыслями, может тем, кто только начинает там свой путь будет полезно. Опять же, это чисто мой опыт, все люди разные, не надо брать мои слова за абсолютную правду. 1) Всегда когда сам ищешь заказ, кажется, что нужен уже какой-то опыт на площадке. Хотя, когда я подбирал себе исполнителя, понял, что этот фактор не так важен (для меня), если всё остальное устраивает. Кажется, что хорошие примеры работ в 100 раз важнее, чем 100500 выполненных заказов. Поэтому я бы не советовал идти и супер занижать себе цену, для того, чтобы “набить опыт” (меня кстати такие люди совсем смутили, готовы делать недельную работу за 1000 рублей). Ну и по поводу примеров работ, был удивлен, что реально мало у кого было что-то похожее на реальный проект. Даже у тех, кто уже выполнил много заказов) 2) Самый важный фактор, по которому я искал человека — это опыт решения тех же проблем. Мне нужен был человек, который может показать мне, как нужно действовать в моей ситуации. Может где-то даст какие-то советы на основе ТЗ, скажет как лучше делать. А в итоге все просто просили точнее расписать каждую деталь. Тут понимаю, что есть куча неадекватных людей, которые будут давать 100 правок, если всё четко не расписать. Решение этой проблемы я не знаю. Так как какое-то количество правок — нормальная практика. Но кажется, идти совсем в другую сторону и требовать всё до мелочей тоже не странно. Мне нужна была голова, а все предлагали руки))) 3) Сам часто слышал, что нужно подробно всё расписывать, когда откликаешься на заказ/вакансию. Когда оказался с другой стороны для себя понял, что толку от всего этого почти нет. Если это только не какой-то полезный совет/замечание по ТЗ. Опять же, все люди разные, по этому тестируйте. Но тонна текста об опыте, кажется, сильно не дает плюсов. А так, опыт прикольный получился. Всем советую попробовать. Можно для теста фейковый заказ выставить, посмотреть на всё с обратной стороны. Лично для себя мне понятно стало, почему я с бирж не мог раньше даже одного заказа получить. Так как от всей толпы откликающихся я ничем не отличался. Писал все те же типовые ответы. А там уже игра идет “кто ниже цену предложит” или “у кого больше заказов высоленных”. А я в итоге понял, что ни с кем из откликнувшихся работать не сильно хочется. Попросил своего друга фронтендера, который еще в дизайне хорош, помочь мне.

Наткнулся тут на новость о том, что Vercel теперь становится hosting-партнером astro. Соответсвенно теперь будут различные плюшки если вы будете деплоить свое asto приложение на Vercel (оптимизация кратинок, edge и тд) Знаю, что многие хейтят Vercel с технической точки зрения, но мне с другой стороны кажется очень умным то, как они ведут свой бизнес). По сути есть различные фичи, которые помогают твоему приложению работать быстрее (сам много не тестил, но людям нравится). Есть тесная интеграция с твоим фреймворками. По итогу ты можешь и в другое место деплоиться, никто не привязывает тебя, но там уже плюшек всех не будет. Даже интересно стало, кто за этим стоит. Так как обычно на видосах/конфах видишь только технарей. Также из интересного, проект Rome (один инструмент для форматирования, линтинга, сборки и тд), которым занимался создатель Babel, перестал поддерживаться. Но по итогу мейнтенеры проекта решили сделать fork и продолжить разработку инструмента. Название оставили похожее — Biome. Вообще сама идея у проекта была прикольная. Есть один инструмент, который может делать сразу все нужные операции над вашим кодом, 1 раз построив AST (давно читал о нем, могу ошибаться). Но, как видите, он не нашел успеха. Интересно, что будет с его предшественником. Ссылки на статьи: https://astro.build/blog/vercel-official-hosting-partner/ https://biomejs.dev/blog/annoucing-biome