Как структурировать проект JavaScript? - PullRequest
14 голосов
/ 05 марта 2012

В настоящее время я работаю над большим проектом JavaScript, для которого мы хотим определить наш собственный API.Я использую RequireJS в качестве загрузчика зависимостей, и он мне подходит, что позволяет мне определять модули в соответствующих файлах.Я не использую свое собственное пространство имен, модуль возвращает экземпляр, который можно использовать в других модулях, например:

define(
    ['imported_module'],
    function(module){
        module.doSomething();
    }
)

Однако, поскольку количество файлов растет, я бы хотел решить, какструктурировать эти файлы в папках.В настоящее время я использую следующую схему для именования своих файлов:

[projectname].[packagename].[ModuleName]

Примером может служить stackoverflow.util.HashMap.js.Я хотел бы представить папку проекта, папку для каждого пакета и переименовать файлы в имя модуля, например:

stackoverflow/util/HashMap.js

Это довольно аккуратно структурирует мой код в папки, однако имя файла теперь отражает только модуль,Я хотел бы определить некоторую разновидность маршрутизации , чтобы определить, как RequireJS должен искать файлы.Пример:

Файл

stackoverflow/util/stackoverflow.util.HashMap.js

должен быть импортирован оператором

define(['stackoverflow.util.HashMap'],function(HashMap){});

Кто-нибудь имел опыт структурирования больших проектов JavaScript и, если да, не могли бы вы поделиться своимподходит?

Ответы [ 2 ]

9 голосов
/ 09 марта 2012

Не следует указывать информацию о маршрутизации в именах файлов js, это задания пространств имен и путей к папкам. Так что stackoverflow / util / HashMap.js просто отлично. И вы можете использовать define ("stackoverflow / util / HashMap", ....) , чтобы определить зависимость.

Если вам нужно поместить модули в разные папки, вы можете настроить пути для вашего загрузчика, см. это руководство из RequireJS API.

Нет лучшего способа структурировать ваши js-файлы. Но помещать корневое пространство имен в папку src - это всегда хорошая практика. Вы можете увидеть исходный код dojo и YUI source code и использовать аналогичные способы для своего проекта. Они оба являются крупномасштабными проектами Javascript.

2 голосов
/ 12 марта 2012

на самом деле лучше, чтобы js lib маршрутизация загружала все js с использованием стандартного интерфейса: «js.yoursite.com/lib-0.2.js» должен быть маршрутизатор (php или другой, и способный кешировать запросы). Таким образом, вы можете определять и контролировать целые пути, которые вы используете. Потому что обычный плагин jquery должен оставаться в одном каталоге с jquery, а ваши собственные пользовательские плагины - нет.

И там вы управляете каждым проектом по своим правилам:

jquery/
  plugins/
    jquery.prettyPhoto.js
  jquery.min.js

mySuperJS/
  stable.0/ -- there your production version for 1.0 branch
    module.js
  0.1/
    module.js
  0.2/
    module.js
  0.3/
    module.js

myOtherlib/
  stable.0/ -- production version for all 0.* versions
  stable.1/ -- production version for all 1.0 versions
  0.1/
  0.2/
  0.3/
  0.4/
  0.4.1/
  0.4.1.18/

Мы используем такую ​​структуру около года, и она лучше для нас. Но иногда мы используем более сложное решение и разделяем все модули на библиотеки, плагины, инструменты, компоненты и приложения.

...