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

[@JoelMiller-z1x]

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

[@PurpleSchool]

Спасибо)

[@АлександрЕлагин-м2ю]

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

[@PurpleSchool]

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

[@АндрейК9-я3ч]

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

[@PurpleSchool]

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

[@ViamoX]

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

[@PurpleSchool]

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

[@dianov7874]

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

[@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. А так можно использовать и то и то.

[@СергейКозлов-н1л]

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

[@PurpleSchool]

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

[@true227]

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

[@aleksandrmatyka3118]

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

[@ЕвгенийЛисицын-ь7т]

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

[@PurpleSchool]

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

[@alexandrkudryashov7170]

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

[@PurpleSchool]

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

[@lirrr6555]

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

[@PurpleSchool]

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

[@sergeyvp]

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

[@PurpleSchool]

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

[@dimitriy8689]

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

[@DFront-t5f]

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

[@PurpleSchool]

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

[@biLLie_wiLLie]

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

[@PurpleSchool]

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

[@CJIu3eHb]

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