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

Сегодня смотрел, что нового происходит в мире JS.

Самое интересное, что я нашел — это выход nest.js v10 и svelte v4.

По поводу nest много сказать не могу, так как я почти не писал на нем.

А вот улучшения по размеру конечного бандла от свелта не плохи, учитывая то, что и так output был у него значительно меньше того же реакт (но меня больше удивило уменьшение размера самого пакета в 4 раза).

Хотя, кажется это только меня и заботило)

Если есть что-то интересное — тоже делитесь в комментариях.

https://svelte.dev/blog/svelte-4
https://trilon.io/blog/nestjs-10-is-now-available

#devtips #js

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

Сразу скажу, что сам вопрос кажется странным.

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

А так вообще у меня в голове нету такого, что если человек знает Х, тогда он джун, а если нет — мидл.

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

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

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

Если все в компании довольны — то может и не должны. Но лишним точно не будет).

Подвел итоги нашего розыгрыша. Победители у нас @iskandaru @VladRylov @hehedev @MikhailS09 @ftsv_d.

Сообщения и индексы их комментариев вы можете увидеть на приложенном скрине.

Дайте поздравим наших победителей!

Всем привет!

Вышло очередное разговорное видео.

На этот раз поговорим про развитие и вещи, которые помогли мне его ускорить.

Оставляйте лайки, фидбэк и делитесь с друзьями!

https://youtu.be/b0YJIfxI2G8

Сегодня помогал человеку с реализацией draggable canvas (по типу миро, но на html).

Столкнулся с проблемой, когда код внутри setState колбэка вызывался 2 раза.

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

setPosition(position => {
const deltaX = e.clientX - prevMousePosition.x;
const deltaY = e.clientY - prevMousePosition.y;
prevMousePosition = {
x: e.clientX,
y: e.clientY,
}

return {
x: position.x + deltaX / scale,
y: position.y + deltaY / scale,
}

В итоге при первом вызове стейт вставал в правильное значение, а при втором — все сбрасывалось, так как prevMousePosition был уже таким же, что и clientX/clientY из ивента.

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

Да, по задумке колбэк должен быть pure function. Но почему нету никакого лога о том, что второй вызов выдал другой результат?

В общем, при обновлении стейта будьте внимательнее.

#devtips #react

Полезная библиотека, если хотите добавить тесты на свои сложные типы:

https://github.com/SamVerschueren/tsd

Всем привет!

Вышел новый собес на моем канале. На этот раз у нас в гостях был Сергей — разработчик из Сбера.

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

Смотрите, оставляйте лайки и пишите в комментариях, где мы ошиблись, или любой другой фидбэк!

https://youtu.be/ElCvv0iFWq4

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

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

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

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

Сам сегодня при подготовке к новому видео зашел в версию React 0.3.0 и был удивлен тем, как там мало кода и как легко его читать.

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

#devtips #opensource

Всем привет!

Хотел сказать, что на этой неделе буду выступать на GDG Tashkent.

Доклад будет на тему написания кастомных ESLint правил.

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

Вот тут все детали митапа:
https://t.me/gdgtashkent/1432

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

Столько презентаций на канале сделал, но не знал про ресурс) Обычно просто скрины из vscode вставлял, но так кажется по лучше выходит.

https://romannurik.github.io/SlidesCodeHighlighter

Пока готовил выступление по ESLint, узнал интересный факт.

Оказывается формат ESTree, который сейчас используется почти во всех инструментах (eslint, prettier, acron, babel и тд) был создан в SpiderMonkey и в какой-то момент был сделан даже публичным.

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

Если посмотреть на доку es5 в ESTree, то можно увидеть, что она почти не отличается от спеки SpiderMonkey (лишь добавленно пару интерфейсов).

Ссылка на старую доку Parser API из FF.
https://udn.realityripple.com/docs/Mozilla/Projects/SpiderMonkey/Parser_API

Еще из интересных открытий, только вчера узнал, что overloads в других языках — это compile time фича (те кто перешел с других языков наверное посмеются).

Причем узнал про это, пока читал о паттерне visitor. Никак не мог понять, почему нельзя просто overload использовать для визитор класса, вместо одного overload метода.

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

Вот тут разбирается все подробно:
https://stackoverflow.com/questions/20219122/what-are-the-actual-advantages-of-the-visitor-pattern-what-are-the-alternatives

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

Минусов у TS много, но и плюсы тоже есть!

Кстати, кто-то пробовал погружать в другие языки? Насколько помогло по другому на все взглянуть?

Я как-то тыкал, но основательно не получалось, так как нужды нет было.

Пока все про using говорят, команда TS подвезла нам очень классные фичи для грядущей версии 5.2.

Декораторы, улучшение туплов, работа с методами массивов и тд.

Уже давно не припомню, чтобы в одном релизе сразу столько болей моих правили (последнее что помню — это 4.1).

https://devblogs.microsoft.com/typescript/announcing-typescript-5-2-beta/#decorator-metadata

#devtips #typescript

Всем привет!

Вышло новое видео на канале, где я в лайв формате пишу кастомное ESLint правило под TypeScript.

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

Чтобы добру не пропадать, решил записать на эту тему видео.

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

https://youtu.be/8kzgX6Awc3M

Всем привет!

Вышло новое видео про синтетическую систему ивентов в React.

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

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

https://youtu.be/edHN-8hZvcU

Одна важная вещь, которую нужно учитывать, если вы предпочитаете использовать типы вместо интерфейсов в TS - это отличие type intersection (`AType & BType`) от наследования интерфейсов.

Давайте для простоты понимания сразу взглянем на пример:

// с типами
type BaseModelType = {
    test: string;
    foo: string;
}

type MyModelType = {
    test: {a: number};
} & BaseModelType;

type TestType = MyModelType['test'];
//    ^?
// { a: number } & string;

// с интерфейсами
interface BaseModelInterface {
    test: string;
    foo: string;
}

interface MyModelInterface extends BaseModelInterface {
//        ^^^^^^^^^^^^^^^^
// Interface 'MyModelInterface' incorrectly extends interface 'BaseModelInterface'.
//   Types of property 'test' are incompatible.
//     Type '{ a: number; }' is not assignable to type 'string'.ts(2430)
    test:  a: number;
};

type TestType1 = MyModelInterface['test'];
//    ^?
// number

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

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

Решение у 2-х проблем одинаковое — использование Omit:

// с типами
type BaseModelType = {
    test: string;
    foo: string;
}

type MyModelType = {
    test: {a: number};
} & Omit<BaseModelType, 'test'>;

type TestType = MyModelType['test'];
//    ^?
// { a: number };

// с интерфейсами
interface BaseModelInterface {
    test: string;
    foo: string;
}

interface MyModelInterface extends Omit<BaseModelInterface, 'test'> {
    test: number;
};

type TestType1 = MyModelInterface['test'];
//    ^?
// number

Не говорю, что нужно использовать одно или другое (я считаю тут просто нужно договориться на уровне проекта), но наследование у интерфейсов по лучше.

#devtips #typescript

Друзья, давайте сегодня вместо поста немного пообщаемся в лайв (минут 30-40).

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