Встречал при изучении языка ещё одно мнение и решил его придерживаться — вообще не использовать этот тип. Мысль была в том, что TS стоит рассматривать как типизированный JS (JS+типы), который не оставляет следа в рантайме, Enum же, напару с Namespaces, генерируют свой код. И в том, что любые навыки, приобретённые при разработке на TS, должны остаться полезными и при возврате на JS (ничто не вечно под луной).
Ещё одна причина — мнимая типобезопасность при использовании не-строковых enum. Если я хочу, чтобы значением было что-то из enum, то я действительно хочу этого, а не вот этого. Строковые enum в этом плане работают куда более ожидаемо.
Ну и в случае, где мне хотелось бы использовать enum, мои потребности покрывает юнион строк.
Не нашёл в статье самого для меня используемого способа: запрещать передавать определённое свойство в интерфейс.
Так как типизация у нас структурная, если при присвоении/передаче в объекте находится больше свойств, чем того требует принимаемый интерфейс, всё будет ок.
Однако, если это не приемлемо, и от передачи каких-то свойств нужно обезопаситься, можно объявить их в интерфейсе опциональными и с типом never, вот так.
Юзкейс из реакта: запретить передавать компоненту children, явно показав, что содержимое не будет использовано:
Можно перефразировать принцип 80/20, сказав, что 80% приложений нужно 20% доступа к аппаратным ресурсам. А эти 20% предоставляются/будут предоставляться в ближайшее время. Остальные приложения, которым действительно нужно не только показать информацию с сервера + посмотреть геопозицию + поработать с картинкой с камеры + прочитать смс с OTP + ещё что-то постое, конечно, останутся на нативных технологиях, вероятно, навсегда. Например, очень маловероятно что мы когда-то увидим на андроиде альтернативное приложение для совершения звонков и управления списком контактов.
Есть файл манифеста, есть файл сервис-воркера, но в текущий момент он не регистрируется, поэтому нет возможности установить как приложение. Выглядит так, как будто эта возможность находится в работе.
А вообще, удивляюсь, что с ними не сотрудничают… Когда на Кинопоиске встретил интересующий сериал в озвучке от Кубик в кубике, например, был очень рад.
&& — вычисление выражения. Для условного выполнения кода есть, например, if и тернарный оператор. Использование && в качестве способа условного выполнения точно также добавляет в код неявности, как и большинство остальных примеров из статьи.
Есть в красном дошике что-то эдакое, что ставит его на голову выше всех конкурентов… А вот остальным да, действительно, можно найти замену и получше :)
Либо автор оригинальной статьи уже исправил этот момент, либо тут очень вольный перевод. aio350 перепроверьте, пожалуйста :)
В дополнение к уже написанному, про Enum.
Встречал при изучении языка ещё одно мнение и решил его придерживаться — вообще не использовать этот тип. Мысль была в том, что TS стоит рассматривать как типизированный JS (JS+типы), который не оставляет следа в рантайме, Enum же, напару с Namespaces, генерируют свой код. И в том, что любые навыки, приобретённые при разработке на TS, должны остаться полезными и при возврате на JS (ничто не вечно под луной).
Ещё одна причина — мнимая типобезопасность при использовании не-строковых enum. Если я хочу, чтобы значением было что-то из enum, то я действительно хочу этого, а не вот этого. Строковые enum в этом плане работают куда более ожидаемо.
Ну и в случае, где мне хотелось бы использовать enum, мои потребности покрывает юнион строк.
Насколько я понял, TS начинает активную поддержку новых proposal, начиная с их перехода на stage 3, т.е. незадолго до включения в стандарт.
Не нашёл в статье самого для меня используемого способа: запрещать передавать определённое свойство в интерфейс.
Так как типизация у нас структурная, если при присвоении/передаче в объекте находится больше свойств, чем того требует принимаемый интерфейс, всё будет ок.
Однако, если это не приемлемо, и от передачи каких-то свойств нужно обезопаситься, можно объявить их в интерфейсе опциональными и с типом never, вот так.
Юзкейс из реакта: запретить передавать компоненту children, явно показав, что содержимое не будет использовано:
Можно перефразировать принцип 80/20, сказав, что 80% приложений нужно 20% доступа к аппаратным ресурсам. А эти 20% предоставляются/будут предоставляться в ближайшее время. Остальные приложения, которым действительно нужно не только показать информацию с сервера + посмотреть геопозицию + поработать с картинкой с камеры + прочитать смс с OTP + ещё что-то постое, конечно, останутся на нативных технологиях, вероятно, навсегда. Например, очень маловероятно что мы когда-то увидим на андроиде альтернативное приложение для совершения звонков и управления списком контактов.
Есть файл манифеста, есть файл сервис-воркера, но в текущий момент он не регистрируется, поэтому нет возможности установить как приложение. Выглядит так, как будто эта возможность находится в работе.
HTA, кстати, похожи на недавнюю "новинку" от Google — Web Bundles.
Прекрасная новость, которую я пропустил! Рад, что ситуация всё же миром разрешилась.
В очередной раз спасибо самому полезному расширению в этой стране, даже не заметил блокировку.
А вообще, удивляюсь, что с ними не сотрудничают… Когда на Кинопоиске встретил интересующий сериал в озвучке от Кубик в кубике, например, был очень рад.
Потыкал код и ссылки из поста и комментов, так и не воспроизвёл выезжание камеры ( Oppo Reno.
Думаю, в комментариях есть место ещё и для такой ссылочки: Deep-copying in JavaScript
&&— вычисление выражения. Для условного выполнения кода есть, например,ifи тернарный оператор. Использование&&в качестве способа условного выполнения точно также добавляет в код неявности, как и большинство остальных примеров из статьи.У чисел есть метод
toString(), который более явен.Опять же, есть более явные
parseInt()и собственно конструкторNumber(), причём между этими способами есть различия.Насколько я помню, функция сортировки должна быть детерминированной. Math.random внутри неё, как бы, не оч.
Только на один уровень. И лучше уж использовать новый
flat()с полифилом.Выглядит, как вредительство. Код становится менее читаемым. Не надо выполнять работу за минификатор.
Веб-компоненты, вероятно, уже есть в вашем браузере (если вы конечно не сидите с IE).