TypeScript - Enums: Обзор и когда не надо использовать

Мы с вами рассмотрим зачем нужны enums в TypeScript и во что они компилируются. А что самое главное - когда их можно использовать, а когда нет.
Полный курс по TypeScript: purpleschool.ru/course/typesc...
Все мои курсы: purpleschool.ru/
Telegram канал с полезными советами: t.me/purple_code_channel

[@user-bk6xu3ue3q]

спасибо, какой вы спокойный мужик. похвально. спокойно объясняете

[@PurpleSchool]

Спасибо)

[@user-sc7by4nv1f]

спасибо за видео, надеюсь видео будут выходить чаще чем статьи на сайте

[@PurpleSchool]

Буду стараться делать хотя бы 1 в неделю. Видео проще записывать мне)

[@user-nh7yl5zg8s]

​ @Anton Larichev жаль что не сказал про Union , мне кажется что интереснее сравнить Enum и Union. А про то , что бизнес логику нужно хранить на беке и так понятно )

[@PurpleSchool]

Можно рассмотреть в отдельном видео)

[@hotsavage66]

Что лучше использовать enum или литеральный тип? Например, у нас есть тип type UserRoles = ‘admin’ | ‘user’ и enum UserRoles {admin, user} и создаётся тип пользователя type User = {name: string, role: ??? }. В этом случае лучше enum или type? При проверке в обоих случаях ts выдаёт ошибку, если правая часть содержит ошибку

[@PurpleSchool]

Enum хороши, когда мы хотим придать смысл значение. Если admin ещё можно понять что относится к роли (да и то только при наведении на тип), то к примеру BYN не сразу очевидно, что это валюта, а Currency.BYN даёт сразу понимание контекста. Особенно это видно с числовыми enum. А так можно использовать и то и то.

[@alexandrkudryashov7170]

а userRole не может разве расшириться? Если например ролевка будет модфицироваться/меняться в зависимости от появления нового сотрудника?

[@PurpleSchool]

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

[@ViamoX]

6:34 - у нас не появилась константа ADMIN, а она уже была в ts в строке 5 (6:21), к тому же она ADMIN, а не Admin

[@PurpleSchool]

Верно, оговорился

[@aleksandrmatyka3118]

Оу, а разве нельзя написать просто вот так? const user = { name: 'admin; } as const

[@user-ux1nf1bs8s]

Только начал изучать TS и не совсем понимаю, чем отличается enum от простого массива при условии, что в enum мы значения не меняем и они остаются по умолчанию 0,1,2...n?

[@PurpleSchool]

Мы может задать любые значения и обращаться не по индексу, а по имени enum

[@user-gp5jm1je8f]

Если честно, не очень понял кейс про то, что enum могут дополняться в дальнейшем и его лучше в таком случае не юзать. Даже если мы будем тянуть значения из базы, к примеру роли, данное значение с сервера все равно нужно типизировать и в любом случае придется править/дополнять описанный тип ранее, пускай даже если он будет обозначен как Union, type Data = {...anything, role: 'admin' | 'user'}

[@PurpleSchool]

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

[@true227]

вроде бы const enum в официальной доке TS советуют не использовать совсем

[@dianov7874]

Антон: просто спасибо ваМ)

[@PurpleSchool]

Пожалуйста)

[@lirrr6555]

Выглядит так, будто я могу не использовать enum вовсе, а предпочитать ему перечисление в типе строковых литералов. Буду ли я в этом не прав?

[@PurpleSchool]

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

[@sergeyvp]

А вот так нельзя просто написать? Без ТС. const users = { admin: 0, user: 1, }; const users2 = { admin: "admin", user: "user", };

[@PurpleSchool]

Без TS все можно написать, ведь TS транспилируется у JS.

[@dimitriy8689]

не совсем понятно, пошел искать дальше

[@user-pp5ek3os5t]

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

[@PurpleSchool]

Не очень понял сформулированное утверждение.

[@biLLie_wiLLie]

Краткое содержание видео - не используйте enum)

[@PurpleSchool]

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

[@CJIu3eHb]

@@PurpleSchool А если куча сервисов - то может надо его просто вынести в shared библиотеку?