AP
рано или поздно вы случайно расширите ваш "глобальный" тип другим локальным типом с таким же названием
Size: a a a
2020 November 11
AS
тем что названия будут иметь коллизии, а ТС типы мержит с одинаковыми названиями
Нууууу ладно, спасибо
AP
так же есть типы которые являются классами, они не могут существовать без самого класса
AP
класс все равно придется импортировать откуда-то, чтобы создать
AP
короче у глобальных типов точно такие же минусы как у глобальных переменных
AP
мы могли бы все в window записывать но в жабаскрипте зачемто модули привезли, наверно не случайно
ER
- если типы нужны только модулю, то хранить и объявлять их внутри этого же модуля
- если типы являются частью публичного интерфейса только одного модуля, то хранить, объявлять и экспортировать в этом же модуле
- если типы описывают какую-то универсальную сущность, которая может использоваться\создаваться в разных модулях, то их надо хранить в отдельном модуле и не смешивать с другими типами. То есть не надо делать файл types.ts и сваливать туда все такие типы, нужно разбивать по разным файлам по доменам использования.
- про d.ts для своего кода можешь забыть, создавать d.ts это работа комплиятора. d.ts нужен только если ты хочешь импортировать npm модуль, а для него нет уже написанной типизации. Тогда ты создаешь d.ts и типизируешь этот модуль сам. Так же через d.ts описываются *.json, *.svg, *.css модули.
Типы вырезаются после компиляции вместе с их импортами, поэтому отделять типы от их реализации без особой нужды бессмысленно
- если типы являются частью публичного интерфейса только одного модуля, то хранить, объявлять и экспортировать в этом же модуле
- если типы описывают какую-то универсальную сущность, которая может использоваться\создаваться в разных модулях, то их надо хранить в отдельном модуле и не смешивать с другими типами. То есть не надо делать файл types.ts и сваливать туда все такие типы, нужно разбивать по разным файлам по доменам использования.
- про d.ts для своего кода можешь забыть, создавать d.ts это работа комплиятора. d.ts нужен только если ты хочешь импортировать npm модуль, а для него нет уже написанной типизации. Тогда ты создаешь d.ts и типизируешь этот модуль сам. Так же через d.ts описываются *.json, *.svg, *.css модули.
Типы вырезаются после компиляции вместе с их импортами, поэтому отделять типы от их реализации без особой нужды бессмысленно
На данный момент, если тип используется только в самом компоненте, держу его в module=context самого компонента. Если же тип встречается слишком часто, то создал main.d.ts, в который указываю:
/// <reference path="./module.d.ts" />
В подобных модулях всегда держу namespaces.
Импорты везде и повсюду надоели и попробовал так, в итоге глобально всё доступно, добавив в tsconfig
"files": [
"src/types/main.d.ts"
]
Пробую всякое, в общем, ради интереса😅
/// <reference path="./module.d.ts" />
В подобных модулях всегда держу namespaces.
Импорты везде и повсюду надоели и попробовал так, в итоге глобально всё доступно, добавив в tsconfig
"files": [
"src/types/main.d.ts"
]
Пробую всякое, в общем, ради интереса😅
AP
На данный момент, если тип используется только в самом компоненте, держу его в module=context самого компонента. Если же тип встречается слишком часто, то создал main.d.ts, в который указываю:
/// <reference path="./module.d.ts" />
В подобных модулях всегда держу namespaces.
Импорты везде и повсюду надоели и попробовал так, в итоге глобально всё доступно, добавив в tsconfig
"files": [
"src/types/main.d.ts"
]
Пробую всякое, в общем, ради интереса😅
/// <reference path="./module.d.ts" />
В подобных модулях всегда держу namespaces.
Импорты везде и повсюду надоели и попробовал так, в итоге глобально всё доступно, добавив в tsconfig
"files": [
"src/types/main.d.ts"
]
Пробую всякое, в общем, ради интереса😅
namespaces это вообще источник неисчерпаемых проблем
ER
namespaces это вообще источник неисчерпаемых проблем
😅почему
ER
Он выглядел логичным выбором, сгруппировал типы, похожие по использованию.
AP
потому что их нет в JS, неймспейс нужен в очень редких кейсах в d.ts файлах для описания стороннего модуля
ER
потому что их нет в JS, неймспейс нужен в очень редких кейсах в d.ts файлах для описания стороннего модуля
Но ведь в JS много чего нет тайпскриптового и все это транспилируется в JS?
AP
но namespace это рантайм фича тайпскрипта, namespace это вполне себе конкретный обьект в рантайме, так же как enum. Все остальное что есть в ТСе не генерирует никаких рантайм штуковин, типы просто вырезаются из кода.
IF
Уже два с половиной года расширяю энамы неймспейсами и никаких проблем
AP
Уже два с половиной года расширяю энамы неймспейсами и никаких проблем
ну никто и на жиквери не запрещает в 2020 писать
IF
ну никто и на жиквери не запрещает в 2020 писать
Конструктивно)
AP
Конструктивно)
Приводить пример проблемы слишком долго, приводить пример насколько неймспейс сковывает дальнейшее развитие тоже слишком долго, тем более чтобы его понять надо будет хорошо подумать. Я уже устал убеждать кого-то в свелте чатике.
Хочешь получать проблемы с транспайл онли режимом, используй неймспейсы.
Хочешь получать проблемы с транспайл онли режимом, используй неймспейсы.
IF
Приводить пример проблемы слишком долго, приводить пример насколько неймспейс сковывает дальнейшее развитие тоже слишком долго, тем более чтобы его понять надо будет хорошо подумать. Я уже устал убеждать кого-то в свелте чатике.
Хочешь получать проблемы с транспайл онли режимом, используй неймспейсы.
Хочешь получать проблемы с транспайл онли режимом, используй неймспейсы.
Так 2.5 года никаких проблем
AP
Так 2.5 года никаких проблем
замечательно
ER
замечательно
Можно ли это как-то продемонстрировать на TS Playground?