@Anton Larichev жаль что не сказал про Union , мне кажется что интереснее сравнить Enum и Union. А про то , что бизнес логику нужно хранить на беке и так понятно )
Что лучше использовать enum или литеральный тип? Например, у нас есть тип type UserRoles = ‘admin’ | ‘user’ и enum UserRoles {admin, user} и создаётся тип пользователя type User = {name: string, role: ??? }. В этом случае лучше enum или type? При проверке в обоих случаях ts выдаёт ошибку, если правая часть содержит ошибку
Enum хороши, когда мы хотим придать смысл значение. Если admin ещё можно понять что относится к роли (да и то только при наведении на тип), то к примеру BYN не сразу очевидно, что это валюта, а Currency.BYN даёт сразу понимание контекста. Особенно это видно с числовыми enum. А так можно использовать и то и то.
Если честно, не очень понял кейс про то, что enum могут дополняться в дальнейшем и его лучше в таком случае не юзать. Даже если мы будем тянуть значения из базы, к примеру роли, данное значение с сервера все равно нужно типизировать и в любом случае придется править/дополнять описанный тип ранее, пускай даже если он будет обозначен как Union, type Data = {...anything, role: 'admin' | 'user'}
Если от этого значения зависит бизнес логика - да. Но если у вас просто выходит сотрудник и нужно его добавить для, скажем, отображения - править код не надо и это экономия. Так же в микросервисах если нужно изменить логику можно изменить в 1-м месте, вместо того, чтобы публиковать для всех новый enum и обновлять все микросервисы по цепочке.
Только начал изучать TS и не совсем понимаю, чем отличается enum от простого массива при условии, что в enum мы значения не меняем и они остаются по умолчанию 0,1,2...n?
Могу меняться, но при добавлении роли нам всё равно придётся менять логику проверки роли и где она используется, поэтому при добавлении новой роли нам нужно будет в любом случаем лезть в код.
Как для технического директора и профессионального разработчика, достаточно слабо прикрыть слова "Не использовать!" таким аргументом. Без обид, думаю это повод тебе копнуть глубже.
спасибо, какой вы спокойный мужик. похвально. спокойно объясняете
Спасибо)
спасибо за видео, надеюсь видео будут выходить чаще чем статьи на сайте
Буду стараться делать хотя бы 1 в неделю. Видео проще записывать мне)
6:34 - у нас не появилась константа ADMIN, а она уже была в ts в строке 5 (6:21), к тому же она ADMIN, а не Admin
Верно, оговорился
@Anton Larichev жаль что не сказал про Union , мне кажется что интереснее сравнить Enum и Union. А про то , что бизнес логику нужно хранить на беке и так понятно )
Можно рассмотреть в отдельном видео)
Что лучше использовать enum или литеральный тип? Например, у нас есть тип type UserRoles = ‘admin’ | ‘user’ и enum UserRoles {admin, user} и создаётся тип пользователя type User = {name: string, role: ??? }. В этом случае лучше enum или type? При проверке в обоих случаях ts выдаёт ошибку, если правая часть содержит ошибку
Enum хороши, когда мы хотим придать смысл значение. Если admin ещё можно понять что относится к роли (да и то только при наведении на тип), то к примеру BYN не сразу очевидно, что это валюта, а Currency.BYN даёт сразу понимание контекста. Особенно это видно с числовыми enum. А так можно использовать и то и то.
Антон: просто спасибо ваМ)
Пожалуйста)
Если честно, не очень понял кейс про то, что enum могут дополняться в дальнейшем и его лучше в таком случае не юзать. Даже если мы будем тянуть значения из базы, к примеру роли, данное значение с сервера все равно нужно типизировать и в любом случае придется править/дополнять описанный тип ранее, пускай даже если он будет обозначен как Union, type Data = {...anything, role: 'admin' | 'user'}
Если от этого значения зависит бизнес логика - да. Но если у вас просто выходит сотрудник и нужно его добавить для, скажем, отображения - править код не надо и это экономия. Так же в микросервисах если нужно изменить логику можно изменить в 1-м месте, вместо того, чтобы публиковать для всех новый enum и обновлять все микросервисы по цепочке.
вроде бы const enum в официальной доке TS советуют не использовать совсем
Только начал изучать TS и не совсем понимаю, чем отличается enum от простого массива при условии, что в enum мы значения не меняем и они остаются по умолчанию 0,1,2...n?
Мы может задать любые значения и обращаться не по индексу, а по имени enum
Оу, а разве нельзя написать просто вот так?
const user = {
name: 'admin;
} as const
а userRole не может разве расшириться? Если например ролевка будет модфицироваться/меняться в зависимости от появления нового сотрудника?
Могу меняться, но при добавлении роли нам всё равно придётся менять логику проверки роли и где она используется, поэтому при добавлении новой роли нам нужно будет в любом случаем лезть в код.
Выглядит так, будто я могу не использовать enum вовсе, а предпочитать ему перечисление в типе строковых литералов. Буду ли я в этом не прав?
Можно вообще не использовать, но он даёт хорошую читабельность для числовых значениях. Для строк строковые литералы подойдут вполне.
А вот так нельзя просто написать? Без ТС.
const users = {
admin: 0,
user: 1,
};
const users2 = {
admin: "admin",
user: "user",
};
Без TS все можно написать, ведь TS транспилируется у JS.
не совсем понятно, пошел искать дальше
Как для технического директора и профессионального разработчика, достаточно слабо прикрыть слова "Не использовать!" таким аргументом. Без обид, думаю это повод тебе копнуть глубже.
Не очень понял сформулированное утверждение.
Краткое содержание видео - не используйте enum)
Не совсем) Если у вас монолит и есть перечисления, которые могут меняться только при изменении бизнес требований, это хороший кандидат на enum)
@@PurpleSchool А если куча сервисов - то может надо его просто вынести в shared библиотеку?