Подтвердить что ты не робот

Какие существуют рекомендации для структурирования кодовых баз TypeScript?

Я работаю с С# в течение многих лет, и в основном я использую однотипный способ делать что-то. Я также люблю помещать файлы во вложенные папки (соответствующие пространствам имен на С#).

Но теперь я создаю мобильное веб-приложение, использующее TypeScript, и считаю себя структурирующим свой код во многом таким же образом. Однако это не работает слишком хорошо:

  • Каждый файл создает оболочку модуля, поэтому, если у вас много файлов с одним и тем же модулем, вывод (в комплекте) содержит много ненужных строк кода.
  • Типы ссылок в других модулях... не так хороши, как в С#, так как вам нужно приписать имена типов с именем модуля.

Первая точка должна быть исправлена, написав небольшой инструмент, чтобы вырезать ненужные обертки модулей из связанного вывода. И я думаю, что мне нужно избегать использования подмодулей и просто вставлять все в один модуль, независимо от расположения файловой системы.

Есть ли лучший способ структурирования кода TypeScript, чем то, что я сейчас делаю/планирую, или что-то вроде выше рекомендуемого? Какие существуют альтернативы, которые стоит учитывать для тех, кто любит принцип единой ответственности?

PS: Я надеюсь, что это подпадает под принципы SO, несмотря на то, что, возможно, является немного субъективным и открытым.

4b9b3361

ОТВЕТЫ

Ответ 1

Вот мои рекомендации.

Веб-сайт

Если вы используете TypeScript на веб-сайте, используйте модули, чтобы заключить полный и автономный блок функций и хранить его в одном файле (если только он не становится неуправляемым). Будьте осторожны в отношении того, насколько доступ к "модулю а" имеет внутренние биты "модуля b".

Связывание и минимизация всего сгенерированного JavaScript в один файл.

Объявите свои модули с помощью

module MyModule {
    // ...
}

И сделайте их доступными для других файлов кода, используя ссылку:

///<reference path="MyModule.ts" />

Веб-приложение

Для веб-приложения вам нужно решить, как script - тяжелые вещи будут. Если все будет легким, относитесь к нему как к веб-сайту. Если у вас будет много скриптов, то AMD будет вашим другом.

В AMD вы можете использовать структуру папок для организации своего кода. Ваши файлы являются вашими модулями, поэтому вместо объявления module MyModule вы называете свой файл MyModule.ts. Затем вы можете организовать свой код, используя структуру папки и файла, и импортировать модули по мере необходимости:

import myModule = module("./Messaging/Async/MyModule");

Итак, подумайте о import как о вашем using, за исключением того, что вам нужно дать ему имя.

Во время выполнения вам потребуется что-то, чтобы позаботиться о загрузке модулей для вас. RequireJS является популярным выбором для этого.

Вы просто добавляете на свою страницу один тег script, который загружает RequiresJS и сообщает ему имя вашего модуля верхнего уровня:

<script data-main="/Messaging/Async/MyModule" src="scripts/require.js"></script>

Серверное приложение

Для серверного приложения почти наверняка захочется использовать CommonJS (который, например, поддерживается по умолчанию nodejs).

Он работает в основном как AMD (AMD фактически основана на CommonJS), за исключением того, что сервер загрузит модули для вас, поэтому вам не нужно включать загрузку модуля script.

Золотая пуля

Это все на самом деле. Вы могли бы использовать привязку стиля веб-сайта для действительно довольно больших программ, если бы захотели - учитывая, что script будет загружен один раз и кэширован, вы можете решить, что первоначальная стоимость стоит простоты.

Поэтому используйте руководство, пока не подумайте, что он не подходит вашей конкретной программе и хочет делать что-то по-другому. Руководство основано на принципе...

  • сокращение количества HTTP-запросов для веб-сайта
  • повышение удобочитаемости и поддерживаемости приложения для веб-приложений и серверов
  • Загрузка только того, что требуется для приложения веб-приложения/сервера.

Ответ 2

Это довольно субъективно, но для того, что стоит, мы используем модули более или менее как пространства имен и, следовательно, группируем связанные классы в одном файле, за исключением нашей модели просмотра, где мы более или менее придерживаемся одного файла = один класс, как и для С#.

Одной из причин этого является то, что при разработке на стороне клиента мы создаем гораздо более мелкие классы и интерфейсы (часто с двумя или тремя параметрами каждый), обычно сгруппированные по работам конкретного компонента или представления и сопоставление их в одном файле просто кажется более разумным.