Как структурировать крупные проекты Polymer с более 100 элементами

Polymer Starter Kit является хорошей ссылкой на запуск проекта Polymer. Вы просто помещаете все свои элементы в папку app/elements. Это работает довольно аккуратно для небольших проектов среднего размера.

Это становится беспорядочным, когда у вас более ~ 30 элементов. Затем вы хотите реорганизовать плоскую папку elements в более глубокую структуру папок, подобную этой:

- elements -- my-module-1 --- my-element-1-1 --- my-element-1-2 -- my-module-2 --- my-submodule-2-1 ---- my-element-2-1-1 ---- my-element-2-1-2 --- my-submodule-2-2 ---- ...

Есть несколько проблем:

  • когда вы хотите демонстрацию и тестирование подмодулей, вам нужно импортировать все зависимости выше каждого определения элемента.
  • вы нарушаете шаблон "все элементы - братья и сестры"
  • Ваши относительные пути становятся беспорядочными (много ../../../my-module-x/my-module-y)
  • у вас либо есть много путей, как ../../../../bower_components, либо вы используете /bower_components, тогда вам нужно перенаправить на свой dev-сервер, и абсолютные пути испортит gulp -vulcanize.
  • С помощью демонстрационной и тестовой папки для каждого элемента структура вашей каталогов растет очень быстро

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

  • Хранилище Seperate Elements
  • Создание многоразовых элементов

Seperate Elements Repository, как в Topeka App работает для ~ 30 элементов, но как только вы достигнете 100 элементов, вы столкнетесь с те же проблемы.

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

Итак, мне интересно, что такое хорошие методы создания больших приложений для Polymer? Есть ли примеры проектов с более чем 30 элементами?

Каковы хорошие практики для повторных операций с репозициями, которые содержат несколько элементов?

Что такое хорошая структура для нескольких точек входа?

В целом: как вы масштабируете проекты Polymer?

Ответы

Ответ 1

У нас есть производственное приложение, обслуживающее до 100 элементов. Нам было удобно группировать несколько элементов внутри папок, чтобы сократить количество репозиториев и папок. Мы все еще делаем всех братьев и сестер.

Существует несколько прецедентов для этого внутри собственных элементов Google. Если вы посмотрите на app-layout и polymfire, они оба содержат несколько настраиваемых элементов.

Сдвиг ума должен помнить, что не каждый элемент должен существовать в его собственном каталоге.

Ответ 2

В вашей проблеме полезно подумать о различии между файловой структурой и структурой URL. Создание веб-сервера для сопоставления файлов в одном месте. Это то, что делает polyserve, и вы можете настроить wct для настройки своего сервера, как он тоже.

Так, например, когда вы создаете один элемент для тестирования, он обычно находится непосредственно в каталоге проекта, но веб-сервер сопоставляет этот родитель непосредственно непосредственно в /components. Он делает то же самое с bower_components, поэтому они появляются на уровне браузера в одном месте. Вот почему ссылки, такие как.. /polymer/polymer.html работают

Я думаю в предложенном выше сценарии, что вы многократно делаете что-то подобное на каждом уровне подмодуля, чтобы каждый элемент мог ссылаться на полимер или его другие веб-компоненты в ../polymer/polymer.html

Конечным результатом будет общая структура проекта "URL", которая выглядит как

-components (elements mapped to this as well as bower_components) 

--mymodule1 
---(mapped so all directories under bower_components are mapped in here)

---myelement1.1
---myelement1.2

--mymodule2
---(mapped so all directories under bower_components are mapped in here)
---myelement2.1
---myslement2,2

Ответ 3

IMO ключом к организации полимерных элементов доходит до разработки решения проблем/страниц. Подумайте о разработке деталей Lego для конкретной модели. Да, вы можете создать много частей, которые имеют очень специфические функции, но лучше сосредоточиться на повторном использовании и дизайне меньше деталей, которые будут охватывать большую часть структуры (базовые элементы), а затем добавить некоторые детали для подстройки (подкраски элементы), чтобы закончить модель. Базовые элементы должны быть простыми и очень общими.

В то время как элементы подкраски вряд ли будут переработаны, они могут остаться со страницей. Базовые элементы, с другой стороны, должны быть помещены в папку, очень близкую к корню с очень описательными именами. По мере развития развития скорость новых базовых элементов будет уменьшаться, а также время, необходимое для разработки новых страниц.

Если дизайн правильный, то как вы классифицируете элементы, не имеет значения, просто поместите их в папку bower_components, если вы не создаете публичные элементы полимера. Все в bower_components следует контролировать с помощью bower.json, чтобы удалить всю папку и использовать bower install для ее повторного заполнения.