С прост пример
Помещения
Напоследък използването на Typescript става все по-популярно.
Съгласен съм с използването на Typescript, типовите системи елиминират голям брой грешки в програмите. Typescript е полезен в някои случаи.
Но Typescript не елиминира типа „проблеми“, които съществуват в Javascript, поне не по време на изпълнение (но това също е мнение). Всъщност наличието на система от типове в Javascript не гарантира напълно имунитет нито срещу „бъгове в типа“, нито от преобразуване на тип (известен още като принуда).
Не съм съгласен, когато някои разработчици казват, че Typescript „улеснява рефакторинга“. Според мен рефакторингът е наистина улеснен, когато целият код е покрит от тестване.
Не съм тук, за да ви кажа дали използването на обикновен Javascript е по-добро от добавянето на Typescript отгоре, можете да го прочетете в много статии, за да добиете представа.
Вместо това ще говоря за това как можем да се опитаме да ограничим и подобрим някои ъглови случаи, когато разработваме в Typescript, но също и в Javascript.
Typescript скрива ДНК-то на Javascript
Когато използваме Typescript, забравяме или просто не знаем, че реалното функциониране наистина е записано в ДНК на Javascript.
Нека вземем простия случай на функция, която събира две числа.
Тази функция е много проста, имаме декларация на функция с два параметъра, тялото на функцията връща сумата от тези два параметъра.
Но какво ще стане, ако един от двата аргумента е NaN.
Това е така, защото NaN в ДНК на Javascript е число.
И така, какво трябва да направим в този случай?
От моя гледна точка в ограничена среда с Typescript това, което е достатъчно, е:
Управлявайки този ъглов случай, чрез използването на Number.isNaN, чудите ли се защо?
Тъй като „Number.isNaN“ в сравнение с неговия глобален брат „isNaN“ не прави принудата (преобразуване на типа) и когато се използва контекстът на кода, той е ограничен в рамките на същото приложение, написано на Typescript. Number.isNaN е достатъчен в този конкретен случай.
Това не е единственият ръбов случай, но има още, в името на простотата избрах това, за да стигна до много важен момент.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/isNaN
Всъщност почти всички IDE ще ви помогнат да не правите грешки, като подадете например низ като аргумент вместо число.
Защитете се, когато вашият код ще бъде използван външно
Да, така е, предпазете се, когато вашият код ще бъде използван външно.
Напоследък създадох проект на Typescript, за да създам обща библиотека, която може да се използва лесно в проекти, които не са строго написани на Typescript.
В крайна сметка това, което ще трябва да излезе от вашия проект, написан на Typescript, ще бъде прост и чист Javascript. И по време на изпълнение няма да има кой да защити вашия код.
Когато излагате функции от вашата библиотека, не се ограничавайте само до начина на мислене, който прилагате, когато пишете проекта си в Typescript.
Вашата проста функция „сума“ може да се използва по начин, който не очаквате.
Запомнете, Number.isNaN проверява дали стойността е NaN, не я преобразува.
С този пример искам да ви накарам да разберете, че използването на Typescript не премахва напълно „проблемите“, които са и ще останат дълго време в ДНК-то на Javascript.
Знам, че този пример е глупав, но с този прост пример се опитвам да ви накарам да разберете, че Typescript не елиминира напълно основното изискване, което всеки разработчик на Javascript трябва да има: Познаване на ДНК на Javascript.
Ето един пример за това как можем да защитим нашата любима функция „сума“.
Лично аз в този случай предпочитам да оставя на потребителя възможността да използва преобразуване на типове. Разбира се, има и други ъглови случаи, с които трябва да се справим. Например “” (празен низ или низ с празни интервали) и null toNumber връща 0. Така че можем да ограничим, за да позволим принудата за низ и да обработваме съответните ъглови случаи. Може да не е най-добрият начин, но най-добрият начин е този, който ви подхожда най-добре.
Но за да се защитите, трябва да познавате Javascript в дълбочина.
Последни мисли
Надявам се, че тази статия е помогнала на някои от вас да разберат потенциала на познаването на инструментите, които използваме в дълбочина.
Всеки от нас трябва да проучи добре инструментите, които използва.
В заключение, използването на помощ за Typescript, но от друга страна, добавя сложност към език, който е добре да се познава задълбочено и изисква познаване на инструменти за компилиране на кода. Защото трябва да владеем това, което използваме, иначе би било все едно да вземем нож, но да не знаем накъде да го държим.
Самият инструмент е полезен, но ако не знаем как да го използваме, можем да пострадаме.
Благодаря за четенето и не се колебайте да добавите коментари за вашите преживявания :)
