Начал использовать TS не так давно и возник вопрос, какие

имеются практики работы с типами?

- Хранить и объявлять типы прямо в компоненте
- Держать все типы в файле и экспортировать
- записать в d.ts файлы

Я немного запутался, помогите советом, пожалуйста

В файлах .model.ts или.enum.ts

почему не d.ts? Чем мне понравился этот подход, то импортировать типы не нужно. Правда, в таком случае требуется namespacing

d.ts то для библиотечных аннотаций. Как раз таки лучше импортировать типы и юзать их. Так когнитивная нагрузка на программиста меньше

Спасибо, понял.

- если типы нужны только модулю, то хранить и объявлять их внутри этого же модуля - если типы являются частью публичного интерфейса только одного модуля, то хранить, объявлять и экспортировать в этом же модуле - если типы описывают какую-то универсальную сущность, которая может использоваться\создаваться в разных модулях, то их надо хранить в отдельном модуле и не смешивать с другими типами. То есть не надо делать файл types.ts и сваливать туда все такие типы, нужно разбивать по разным файлам по доменам использования. - про d.ts для своего кода можешь забыть, создавать d.ts это работа комплиятора. d.ts нужен только если ты хочешь импортировать npm модуль, а для него нет уже написанной типизации. Тогда ты создаешь d.ts и типизируешь этот модуль сам. Так же через d.ts описываются *.json, *.svg, *.css модули. Типы вырезаются после компиляции вместе с их импортами, поэтому отделять типы от их реализации без особой нужды бессмысленно

Я в context=module описываю сейчас и экспортирую оттуда же. Это для компонентов, а если общие то папочка types

Хм, по поводу d.ts может я чего не понял, но как же настройка генерирующая эти файлы при компиляции сорцов?

Есть npm модули написанные на JS и для которых нет встроенных тайпингов и нет тайпингов в репе DefinetelyTyped. Чтобы их использовать в тайпскрипте придется написать для них d.ts (если конечно тсконфиг не бесполезный который позволяет все что угодно). Это один из обычных кейсов где нужно писать руками d.ts файл. В остальных случаях сам tsc их генерирует при компилции кода =)

А кстати, всегда интересовало, чем в таком случае плохо держать типы в отдельных файлах и иклудить их на уровне компилятора, а в файлах использовать declare? Если что, не работал с ТС в Свелт, мб там есть какие-нибудь особенности на этот счёт?

тем что названия будут иметь коллизии, а ТС типы мержит с одинаковыми названиями

Нууууу ладно, спасибо

На данный момент, если тип используется только в самом компоненте, держу его в module=context самого компонента. Если же тип встречается слишком часто, то создал main.d.ts, в который указываю: /// <reference path="./module.d.ts" /> В подобных модулях всегда держу namespaces. Импорты везде и повсюду надоели и попробовал так, в итоге глобально всё доступно, добавив в tsconfig "files": [ "src/types/main.d.ts" ] Пробую всякое, в общем, ради интереса😅

namespaces это вообще источник неисчерпаемых проблем

😅почему

а ну значит я тебя не правильно понял.

а как же co-location.)))) так то и стили можно писать в отдельных файлах и шаблоны с логикой.

Если в проекте используется реэкспорт, то как лучше называть имена эскпортируемых из контекста типов?

Универального способа не знаю. Сам пару раз сталкивался. Решал на уровне реэкспортов, оставляя имена внутри самих компонентов максимально простыми и очевидными

Понял, спасибо

а в context=module реактивность и остальные плюшки работают (биндинг в шаблон и пр.)?

👍 лучший из всех подходов. Сам так же делаю, и другим советую

про d.ts чуть спорный момент - к примеру в него удобно складывать интерфейсы и шарить между проектами в монорепе. Там хорошо живут контракты апи к примеру, и не нужно их импортить через кучу .. или алиасы

Мне тоже показалось удобным без импортов. Хотелось именно для каких-то глобальных типов для проекта, а не специфичных для данного компонента. Но сторонников такого подхода оказалось мало😅

они так же хорошо живут в отдельном пакете и импортятся оттуда