Представете си случая, в който вашият бекенд ви изпраща данни, където всеки обект има опорен тип и стойностите са ограничени до списък от определени низове. Нека за по-голяма яснота кажем, че пишем приложение за зоопарк и изискваме списък с всички животни.
Знаем, че зоологическата градина може да отглежда само някои определени животни, това са:
- Котки
- Кучета
- Змии
- Маймуни
Не ме питайте защо тези , те бяха първите, които изникнаха в съзнанието ми :)
И нашият бекенд връщаше тези типове като: "котка", "куче", "змия" или "маймуна".
Така че, ако сега просто поискаме идентификатора, името и типа на животните, можем да създадем тип, изглеждащ така:
И всичко това е добре за много случаи, но си представете, че искаме да извършваме действия въз основа на вида на животното. Можем просто да напишем превключвател за този пример, но когато работим с повече хора и по-големи обекти с повече възможности, искаме да сме по-стриктни относно това, което е възможно, за да избегнем човешка грешка. За да бъдем по-стриктни, ние решаваме да ограничим типа животно до единствените възможни опции.
В примера по-горе вече е строго какво може да бъде нашето животно. По този начин намаляваме времето, прекарано на други лица за търсене на всички възможни случаи. Но все пак трябва да напишем типовете и пак можем да правим печатни грешки. Така че всъщност бихме могли да създадем съпоставяне, но в Typescript имаме enum и от 2.4 те позволяват инициализатори на низове. Това ни позволява да имаме строго типизирано животно и при създаването или сравняването на животни избягваме правописни грешки.
Както можете да видите, горното решение прави живота ни много по-прост. Особено когато имаме 10+ вида. Разбира се, не бих препоръчал този начин всеки път, но в случаите, когато имате ограничен набор от възможности и са необходими много проверки, определено бих избрал този подход. Освен това, тъй като това се преобразува в низ зад кулисите, нашият бекенд все още просто ни изпраща низа с типа и не е нужно да правим нищо специално, за да работи нашата част.
