Сегодня большинство фронтенд-разработчиков вовлечены или даже глубоко используют машинописный текст, но вы можете совершать следующие ошибки.
- В вашем проекте не включен строгий режим
Строгий режим может устранить некоторые необоснованные и неточные места в грамматике и может заставить TS развиваться в более разумном, безопасном и строгом направлении: заменяя некоторые тихие ошибки TS на бросающие ошибки, некоторые ошибки TS устраняются.
Замалчивание ошибок может более эффективно обеспечить безопасность выполнения кода; улучшить эффективность компилятора и увеличить скорость работы; запретить некоторые синтаксисы, которые могут быть определены в будущих версиях ECMAScript.
2. Самая распространенная ошибка – использованиеany, когда вы точно не знаете, как определить тип
Когда мы не уверены в типе данных, используется тип данных any. Но правильно использовать вместо него unknown.
Почему? any прост, потому что он принципиально отключает все проверки типов. В общем, используйте любой даже в официальных видах. Это в основном отключает проверку всех типов. Все значения, поступающие через any, полностью исключат проверку типов. Это может стать очень трудным для обнаружения ошибок, потому что код будет давать сбой только в том случае, если наши предположения о структуре типов совпадают с кодом времени выполнения.
3. val as SomeType
Вы можете заставить такой тип сообщить компилятору, что он не может его вывести.
Когда мы хотим преобразовать JavaScript в TypeScript, существующие кодовые базы часто делают предположения о типах, которые компилятор TypeScript не может получить автоматически. В этих случаях использование fast в качестве SomeOtherType может ускорить преобразование без ослабления настроек в tsconfig .
Вот для чего нужны защиты типов:
4.необязательные атрибуты
Определите свойство как необязательное свойство, которое иногда существует, а иногда нет. Вы можете кодировать интерфейс следующим образом:
На самом деле лучше четко выразить, какие комбинации моделей существуют, а какие не существуют.
Определение свойств как необязательных, а не типизированных проще и генерирует меньше кода. Это также требует четкого понимания разрабатываемого продукта и может ограничить использование кода при изменении предположений о продукте.
Самым большим преимуществом систем типов является то, что они могут заменить проверки во время выполнения проверками во время компиляции. Благодаря более быстрой печати ошибки, которые могут остаться незамеченными, можно проверить во время компиляции.
5. Используйте букву в качестве общего параметра
Используйте букву в качестве имени, например, обычно используемую букву T в качестве общего имени!
Лучшим способом было бы дать полностью описательное имя типа.
Это плохая привычка, потому что даже в официальной документации используются однобуквенные имена. Нажатие T вместо полного имени ускоряет набор текста и не требует особых размышлений.
Универсальные типы являются переменными, как и любая другая переменная. Когда IDE начали показывать нам эти технические особенности, мы отказались от идеи описывать технические особенности переменных в именах переменных. Например. Обычно мы просто пишем const name = ‘My’ вместо const strName = ‘My’. Кроме того, однобуквенные имена переменных часто являются хитом, потому что может быть трудно перевести их значение, не глядя на их объявления.
6. нелогическая проверка
Во многих случаях мы будем использовать ложное значение в качестве условия суждения.
Может, стоит подумать о том, что мы действительно хотим проверить. Например, приведенный выше пример по-разному обрабатывает случай, когда count равен 0.
7. ! ! оператор
Для некоторых из нас, поймите! Простой. Он выглядит коротким и лаконичным, и если вы уже знакомы с ним, вы знаете, о чем он. Это простой способ преобразовать любое значение в логическое значение. Особенно в кодовых базах, где нет четкого семантического разделения между ложными значениями, такими как null, undefined и ''''.
Используйте !!, чтобы скрыть то, что на самом деле означает код, продвигая внутренние знания. Это делает кодовую базу менее доступной для новых разработчиков, как новичков в общей разработке, так и новичков в JavaScript. Также легко ввести незаметные ошибки. Проблема с тем, что countOfNewMessages равна 0 из-за «нелогической логической проверки», все еще существует !! .
Если вы также совершаете вышеуказанные ошибки, мы можем попытаться избежать подобных ошибок. Если вы избежали этих ошибок, поздравляем! у вас есть предварительное представление о Typescript.
