Enums - зло? Или мы просто не поняли замысел творца?

Вокруг enums в TS ходит большое кол-во споров. Кто-то их любит, кто-то ненавидит. Я был и в том, и в другом лагере. Давайте посмотрим на их плюсы и минусы(по моему мнению), чтобы вам было проще вывести для себя ответ. ВАЖНО!!! Я не призываю отказываться от enums, просто призывая подумать.

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

enum BookGenre {
  horror = 1,
  comedy = 'comedy'
}

➕:
Строковые enums удобны.
Вы сразу и константы сгруппировали по смыслу, и тип сделали. Лаконично и наглядно.

enum BookGenre {
  horror = 'horror',
  comedy = 'comedy'
}
function logGenre(genre: BookGenre) {}
logGenre(BookGenre.comedy)

➕➖:
Нелогичное поведение при проверке значений.
В данном примере значение у элемента энама идентично строке, но в TS будет ошибка. Где-то это +, мол, мы явно говорим использовать только конкертный enum, где-то минус, бэкенд присылает вам просто строку, и тут вам будет недостаточно просто проверить значение, нужно писать тайпгард.

logGenre(BookGenre.comedy)
logGenre('comedy') // error

Реверсивность.
Числовые элементы enum(в значении число) являются реверсивными: по ключу получаем значение, по значению ключ. Выглядит это так:

enum BookGenre {
  horror,
  comedy
}
console.log(BookGenre.comedy) // 1
console.log(BookGenre[1]) // comedy

Иногда это может вам пригодиться. Но как поведет себя вот такой энам?

enum BookGenre {
  horror = 1,
  comedy = 1
}
console.log(BookGenre[1]) // ?

Ответить на этот вопрос мы можем, если посмотрим в результат компиляции этого enum:

var BookGenre;
(function (BookGenre) {
    BookGenre[BookGenre["horror"] = 1] = "horror";
    BookGenre[BookGenre["comedy"] = 1] = "comedy";
})(BookGenre || (BookGenre = {}));

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

console.log(BookGenre[25])

Логично было бы увидеть тут ошибку, т.к. у нас нет элемента со значением 25, но нет, ошибки от TS мы не увидим.

➖:
Лишний код.
Часто enums используют просто для типизации. Но не все задумываются, во что эти энамы компилируются. Многие уже привыкли, что типы в скомпилированный код не попадают… Тудуууум:

var BookGenre;
(function (BookGenre) {
    BookGenre[BookGenre["horror"] = 1] = "horror";
    BookGenre[BookGenre["comedy"] = 1] = "comedy";
})(BookGenre || (BookGenre = {}));

Знакомьтесь, ваш энам. И он поедет с вашим кодом к пользователю, даже если вам от него нужны только типы. И если у вас их много, то и лишнего когда у вас много.

Кто-то предложит использовать const enum. Я очень часто разрабатываю пакеты, поэтому нет, спасибо. Дока.

Они мерджатся.
Давайте взглянем на такой код:

enum BookGenre {
  horror = 'horror',
  comedy = 'comedy'
}
// много строк между
enum BookGenre {
  drama = 'drama'
}

В нем нет ошибки, он рабочий. Скомпилируется он в:

var BookGenre;
(function (BookGenre) {
    BookGenre["horror"] = "horror";
    BookGenre["comedy"] = "comedy";
})(BookGenre || (BookGenre = {}));
(function (BookGenre) {
    BookGenre["drama"] = "drama";
})(BookGenre || (BookGenre = {}));

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

Что делать если вы решили заменить часть или все ваши энамы. 🔽

Конференции😀

Сейчас еду в поезде из Питера с HolyJs и решил поделиться с вами своими мыслями о конфах.

Что для меня конференция

1. Мотивация🔥. Я много раз говорил о том, что люблю Яндекс, Шри за возможность работать с очень мотивированными людьми(берем среднее по больнице), которые горят своим делом. Конференция это еще одно такое место. Рассказы о каких-то новых хитроумных велосипедах, героически решённых сложных задачах, общение с увлеченными инженерами очень сильно меня мотивируют и заряжают энергией(даже перекрывают недосыпы😴)
2. Расширение кругозора👨‍💻. Какие бы мы любопытные не были у нас не всегда есть возможность попробовать что-то новенькое во всех возможных кейсах, а если эта технология еще и не входит в ваш стек(потенциальный стек), то вероятность становится еще меньше. И если с новинками в вашем стеке все понятно, то с решениями за его пределами возникает резонный вопрос - зачем мне вообще про них слушать? Для меня технологии это в первую очередь реализация идей, задумок, которые могут прокачать уже ваши решения, натолкнуть на новые мысли и идеи.
3. Общение📞. Конфа это возможность пообщаться 1-1, подискутировать, обменяться опытом, идеями. Это возможность узнать, как устроено где-то еще, кроме вашей компании/проекте/коллективе, познакомиться с другим взглядом на ежедневные рутинные задачи и проблемы.

Ну и бонусный пункт — конференция это весело🥳

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

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

А чем конференции интересны вам?

Server components🤓

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

Что это такое?🤔

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

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

Их «статичность» накладывает определенные ограничения:

1. Нельзя поменять отображение
2. Нельзя использовать API браузера
3. Нельзя использовать (как и большую часть API React)

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

Вопрос: зачем нам серверные, если у них столько ограничений?

Простейшая загрузка данных🛞

export default async function Movie({ movieId }) {
  const movie = await getMovie(movieId); // запрос на сервер

  return <main>Movie: {movie.name}</main>;
}

Код, необходимый для их рендеринга, остается на сервере👍

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

Клиентской части механизма рендеринга React эти компоненты неинтересны совсем (почти)😴

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


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

Работяги, поменял фото канала, не теряйте)

Всем хорошего рабочего дня и недели👨‍💻

Введение в паттерны и архитектуру🏠

Работяги! В прошлом опросе тема архитектуры и паттернов набрала больше всех голосов, поэтому буду стараться писать о ней чаще.
Реакт на втором месте, поэтому скоро тоже будет.👨‍💻

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

🧑‍🎓Нам понадобится:

1. «Паттерны объектно-ориентированного проектирования» Эрих Гамма, Ричард Хелм, Роберт Джонсон, Джон Влиссидес — знаменитая книга банды четырех. Кто-то ее списал в утиль, но не я. Считаю ее базовой, нужно лишь адаптировать рецепты под свою область.

2. «Рефакторинг-гуру» — великолепный материал. Как книга банды четырех, но более простым языком и с большим кол-вом примеров(есть и на TS).

3. «Dive Into DESIGN PATTERNS» Oleksandr Shvets — замечательная книга для новичков в архитектуре и паттернах от создателя «Рефакторинг-гуру».

4. Сайт Эдди Османи — топ-труд по шаблонам для фронтендера. У Эдди есть еще и книги, если хотите, можете и их почитать, они хорошие.

5. «Чистая архитектура. Искусство разработки программного обеспечения» Роберт Мартин — последняя в списке, но не последняя по значению.

👨‍💻Теперь инструкция:

1. База-базовая. Читаем книгу «Dive Into DESIGN PATTERNS» Oleksandr Shvets. Читаем всё до главы «Каталог паттернов». Эта часть объяснит нам, что вообще такое эта архитектура, зачем о ней думать, какие базовые критерии есть и где в этом всем паттерны. Расскажет про солид, который станет базой для наших решений.

2. Паттерны. Далее начинаются паттерны. Читаем по одному паттерну с сайта «Рефакторинг-гуру». Смотрим на этом же сайте пример на TS. После этого читаем про него же у банды четырех(там написано максимально сухо и академично, но классический вариант знать надо). После этого смотрим на сайт Эдди Османи, если наш паттерн есть там, то читаем его. В итоге мы получаем следующую картину: понятное описание + пример на TS + классическое описание + адаптация под JS/Frontend. Таким образом у вас будет полная картина о каждом паттерне, останется шлифануть практикой.

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

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

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

1x1: о фронтенд-разработке в Яндексе

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

Приятного просмотра и хорошего всем дня👨‍💻

Обратная сторона React

Здарова, работяги!

Как я понял из опроса выше, всем очень интересен React🖼️ и очень интересна архитектура. Поэтому начинаем холиварную тему про архитектуру в приложениях со старым добрым(так ли это?) реактом.

Не буду лить воду, обойдемся без подводочек — такого большого кол-ва страшных приложений, как на React, я больше ни на одной другой технологии не видел. Кто-то пошутит, что просто на других технологиях самих приложений очень мало, особенно на моем любимом Angular💻, вот я их и не видел. В этом есть доля правды, но лишь доля. Даже если смотреть отношение страшненьких проектов к реально хорошим, React в топ не выбьется, по моему опыту. Почему так?🤔

Уже около года я много занимаюсь разработкой на чистом ts 💻 и js 💻. И знаете, что я вам скажу. Это сильно отрезвляет. Да, именно так, отрезвляет. Этот опыт помог мне взглянуть на приложения с React иначе.

У React много проблем, это факт. Но есть одна, которая стала сейчас для меня очень отчетливой. Необычность этой проблемы в том, что она одновременно и его главный плюс. React — библиотека. Да, все так просто. React не фреймворк, а лишь библиотека для построения ui слоя вашего приложения. Только лишь одного слоя — UI.

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

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

Скорее всего, у многих в проекте стоит линтер, скорее всего, у многих в правилах линта есть правило проверки зависимостей в хуках useEffect и подобных. А теперь обратите внимание на те места, где это правило замьючено. После анализа большого числа таких мест я пришел к следующему выводу — чаще всего такие мюты появляются в тех случаях, когда зависимостей слишком много(лишние срабатывания происходят и т. п.), а много их из-за того, что логика в эффекте избыточна, что именно в этом месте вы переборщили и занесли в ваш легкий ui лишнего. Конечно, есть исключения, но их, по моему мнению, сильно меньше. В большинстве же своем это именно проблемные места, которые если еще не болят, то скоро будут, т. к. такие эффекты крайне сложно поддерживать из-за обилия зависимостей, логики, большого кол-ва срабатываний и т. д., поэтому разработчики просто мьютят линтеры и замалчивают проблему.