Всем привет!

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

Решил раз и на всегда написать пост, чтобы можно было на него ссылаться.

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

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

Так вот, касательно плюсов классов:

1) Мне просто нравится, что в TS сразу же у тебя сгенерируется тип для твоего инстанса, в случае с функцией нужно создавать интерфейс либо же юзать ReturnType<typeof createSomeObject>.

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

3) Также несмотря на проблемы с наследованием, прикольно юзать его на 1 уровень. Например, тот же EventEmitter так используют часто и React раньше использовал подобный паттерн для компонентов.

Я сам подобные наследуемые классы редко пишу, но для библиотек может быть полезно.

В остальном, сильных предпочтений не имею. Насколько я знаю, классы лучше оптимизируются самим V8 (вот тут на 100% не уверен), но зато плохо анализируются различными сборщиками. Часто из-за них ломается tree shaking.

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

В общем, правильного пути тут нет, просто делаюсь своим мнением. Всем хорошего вечера!

#devtips #classes

Сидел тут лазил в исходинках React (хотел уточнить один момент касательно батчинга), и наткнулся на такую вещь, как navigator.scheduling.isInputPending.

Решил загуглить, оказалась, что это АПИ которое позволяет узнать, есть ли какие-то ивенты от пользователя, ожидающие обработку.

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

Подробнее про саму эту фичу можно почитать вот тут — https://developer.chrome.com/articles/isinputpending/

Из минусов, поддержка на данный момент только в Chrome. Учитывая то, что вышла статья в 2020 - кажется, что особого интереса в реализации у других браузеров нету.

UPD: кажется, что есть пропоусал на добавление в стандарты — https://github.com/WICG/is-input-pending

#devtips #js #react

Всем привет!

Вышло новое видео про то, как использовать throttle и debounce в React. Разберем в каких кейсах они нужны, как их использовать и в конце уже напишем универсальные хуки.

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

https://youtu.be/uhQKo4AS4z8

Всем привет!

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

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

Мой ресерч как раз привел на их статью о релизе превью для 16-й версии, и я прямо реально удивлен.

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

Хотя... вроде бы в 12-ой версии они уже начали тестировать esbuild, тут думаю меня поправят, если память мне изменяет.

Однако 16-ая версия выглядит реально круто. Добавили сигналы и их интеграцию с observables из rxjs, сборку с помощью esbuild для прода и vite для дева, clients-side гидрацию (был удивлен, что ее не было до этого).

Подробнее можно почитать тут:
https://blog.angular.io/angular-v16-is-here-4d7a28ec680d

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

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

Как-то так. Всем хорошего вечера!

#devtips #news

Всем привет!

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

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

Однако недавно наконец осознал то, насколько все это не удобно, особенно когда нужно записывать видео.

У меня обычно максимальная креативность/продуктивность в утреннее время. А пока встанешь, оденешься и дойдешь до коквркинга, состояние уже не то.

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

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

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

Так что всем советую обустроить удобнее рабочее место. Сам теперь жалею, что не сделал это раньше.

#devtips #work

Всем привет!

Сегодня хотел бы поговорить про лимит роста в качестве разработчика.

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

В первую очередь, какие есть способы роста у разработчиков?

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

Однако после нее как раз и начинаются проблемы. Какие есть пути дальше?

1) Самый очевидный - расти в лида и дальше идти в сторону менеджмента.
2) Расти в principle/staff инженера (везде называют по разному), но смысл заключается обычно в том, что ты ведешь какой-то технически сложный проект, который влияет на большую часть компании.
3) Лучше изучить смежные сферы - бек, девопс и двигаться куда-то в сторону архитектора, СТО.

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

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

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

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

Касательно архитектора/сто, думаю примерно тоже самое, только в данном случае вы заведомо не должны писать код. Позиция наверное чаще встречается и в обычных фирмах, чем staff/principal, но в бигтехе думаю на нее проще выйти в силу большого кол-ва продуктов и быстрого развития. Хотя тема спорная - поделитесь мнением в комментариях.

Ну и лид/менеджер - думаю про этот путь все знают. Почему я отделил это от СТО? Потому что тут можно как раз расти в продуктовую сторону.

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

Наверное еще один путь, который я не упомянул - это найти комфортный для себя уровень и уже от туда начинать запускать свои проекты. Кто-то идет в сторону заказной разработки, кто-то в сторону SaaS и стартапов, кто-то (например я) начинает вести канал/блог, а кто-то просто перестает активно развиваться - вариантов тут много.

Как вы можете понять, последний вариант мне кажется самым интересным. Почему?

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

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

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

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

Также стоит учитывать, что до подобных позиций люди доходят очень долго. Я помню в Яндексе смотрел сколько топ менеджеры работают в компании. Обычна эта цифра была где-то 8-15 лет. За этот срок при тех же усилиях кажется можно добиться более высоких результатов, если идти в сторону своих проектов/бизнеса.

Опять же, не пытаюсь продать вам данную идею, так как минусов тоже очень много:

- Нету четкого плана, графика, целей и вектора развития. Все на вас. Можно просто потратить кучу времени в никуда.

- У разных людей разные навыки. Кому-то проще работать в маленьких командах/компаниях и запускать продукты с нуля, кто-то хорош в управлении и скейлигне.

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

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

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

Надеюсь для тех людей, которые не задумывались о своих следующих 5-10 годах карьеры, я смог подбросить мысли на подумать.

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

#devtips #career

Всем привет!

Наткнулся на статью по торгу ЗП на Linkedin — всем советую для ознакомления. Она заточена больше под FAANG и большие компании, но большая часть пунктов и для маленьких компаний подойдет.

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

https://www.lennysnewsletter.com/p/negotiating-comp

Недавно сидел тут и думал про инструменты для JS и как сейчас все движется в сторону написания тулзов на Rust.

Однако один момент, которые мне интересен, почему даже после того, как TS стал чуть ли не стандартом индустрии никто не делает сборщик, который мог бы оптимизировать код на основе описанной типизации?

У гугла уже давно есть clouser-compiler, который может не плохо так оптимизировать ваш код, однако он требует JSDoc аннотации для того, чтобы лучше понимать ваш код.

Кажется, можно было бы просто завязаться на TS, хотя наверное во время его создания он был еще не так популярен. Написан, он кстати на Java, а не на JS.

Также был неудачный проект от Facebook под названием Prepack, который мог еще более агрессивно оптимизировать код с помощью частичного запуска. Но там вообще информация о типе не использовалась.

А вообще наверное самым идеальным вариантом была бы ситуация если доехали бы optional types до JS, тогда уже на основе этой информации сами движки могли бы делать много оптимизаций.

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

А что вы думаете по этому поводу? Приходили ли вам подобные мысли?

Всем привет!

Вышло новое видео, в котором я разбираю изменение в работе React 18, о котором я не знал. Поговорим про то, что это за изменение и как оно влияет на ваш код.

Обязательно оставляйте лайки и фидбэк в комментариях. В следующем видео буду разбирать то, как все-таки поправить хук useOutsideClick для того, чтобы он работал в React 18, и также бонусом поделюсь хуком для работы с вложенными модалками/тултипами/окнами.

https://youtu.be/ARtc9geJRUM

Всем привет!

Что-то нету желания и сил писать длинный пост, поэтому ловите небольшой пример того, как memo может портить ваш тришейкинг и как это поправить.

Если интересны детали — можно разобрать все в отдельном видео/серии видео про сборку.

https://bit.ly/3pASuBl

#devtips #bundlers

Всем привет!

Как и обещал в прошлом ролике, сделал видео про хук для обработки кликов вне элемента (useOutsideClick).

Также бонусом добавил хук useLayerManager, который поможет вам работать с вложенными окнами (например модалка => дропдаун => тултип).

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

https://youtu.be/-l9dECM-8gE

Всем привет!

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

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

Я когда в первый раз увидел такие договоренности на проекте, то был очень удивлен. Ведь в большинстве случаев рендер компонента и так быстрый, а мемоизация добавляет сложности с актуализацией депсов в useMemo/useCallback.

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

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

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

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

А в других случаях я бы предпочел все равно использовать мемоизацию только там, где это нужно. Можно придерживаться таких правил:
- Мемоизируем все пропсы для компонентов из внешних библиотек (если точно не знаем, что там внутри).
- Мемоизируем пропсы для компонентов, которые используют memo.
- Если есть пропсы откуда-то с верхнего уровня и они не мемоизированы - можно использовать useEvent/useLatest для того, чтобы избежать лишних обновлений.

Также хотел бы отметить, что если уж и мемоизировать все подряд, то намного проще использовать самописные хуки useEvent и useLatest, так как большинство колбэков вообще никогда не должны обновляться.

#devtips #react #hooks

Всем привет!

Наверняка многие из вас уже успели посмотреть мое последнее видео про всплывающие окна.

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

Так вот, впервые я увидел данную технику в коде react-redux, и тогда я не совсем понял, для чего это вообще нужно.

Затем через какое-то время наткнулся на issue про stale props и zombie children и на пост приложенный ниже о том, как данная проблема была решена для connect.

В целом, статья очень полезная для понимания redux и многих его концептов.

Да, он уже не настолько актуален после появления react-query и других cache management решений, однако все равно считаю ее очень полезной. Как минимум для общего кругозора.

А если повезет, может как и я извлечете пару полезных идей для своих проектов!

https://kaihao.dev/posts/Stale-props-and-zombie-children-in-Redux

#devtips #react #redux

Всем привет!

6 мая я пропустил пост, а в последней неделе апреля у меня было только 1 видео. Поэтому давайте проведем розыгрыш.

Для тех, кто не в курсе, я пообещал выпускать 2 видео в неделю и 1 пост в день на протяжении 2023-го года. За каждый пропущенный видос или пост я разыгрываю $50 или 1:1 сессию коучинга.

В этот раз, как могли уже понять, будет 2 победителя.

Для участия нужно будет оставить ровно 1 комментарий под следующим постом. Победителей выберу на этой неделе (не раньше, чем через 24 часа).

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

Всем привет!

Сегодня снимал видео, где я писал сигналы с нуля. Так вот, во время подготовки к видео смотрел реализацию в preact и angular и наткнулся на README в репе ангуляра, где объясняется их реализация.

Узнал для себя несколько интересных моментов. В целом, если вам было интересно, как все работает под капотом — то советую почитать. Особенно понравилось использование valueVersion и trackingVersion.

Помню еще до того, как вышла 16-я версия было очень много разговоров в rfc и долго шли обсуждения. Тогда мне это показалось очень странным, ведь простой вариант реализовать не так уж и сложно.

Однако сейчас вижу, что они все очень круто продумали с точки зрения оптимизаций и различных edge case’ов.

https://github.com/angular/angular/tree/main/packages/core/src/signals

#devtips #signals

И так друзья, подвел итоги розыгрыша! Победители у нас @kudin_tn и @gusso с комментариями под индексами 230 и 58 соотвественно.

Давайте поздравим ребят!

Также, скорее всего не успеваю со вторым видео. Думал, что можно завтра провести первый лайвстрим на ютуб, порешать задачки на ТС и пообщаться. Что думаете, засчитываем это за 2-е видео?