Как структурировать большие полимерные проекты с более чем 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, тогда вам нужно иметь перенаправление на вашем сервере разработки, и абсолютные пути испортят gulp-vulcanize.
  • С демонстрационной и тестовой папкой для каждого элемента ваша структура каталогов растет очень быстро.

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

  • Отдельный репозиторий элементов
  • Создание повторно используемых элементов

Отдельный репозиторий элементов, как в приложении Topeka, работает примерно для 30 элементов, но как только вы 100+ элементов, вы сталкиваетесь с теми же проблемами.

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

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

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

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

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


person LinusK    schedule 29.10.2015    source источник
comment
На самом деле никакой помощи в вашей текущей проблеме. Но я смотрел несколько видеороликов PolymerIO, где рассказывалось о планах по упрощению использования включения зависимостей (может быть, автоматически импортировать нужные зависимости?). Другими словами, даже если это проблема для вас в данный момент, в ближайшем будущем это может стать намного проще. :)   -  person Whyser    schedule 30.10.2015
comment
Вероятно, вы имеете в виду Polygit? Magic Server обслуживает файлы напрямую с github. Это немного упрощает создание нескольких репозиториев (поскольку вам не нужно делать bower update после каждого изменения), но вам все равно нужно будет зафиксировать 100 репозиториев, если вы будете следовать стандартному подходу к многоразовым элементам...   -  person LinusK    schedule 30.10.2015


Ответы (3)


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

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

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

person drasticp    schedule 30.11.2016

В вашем вопросе полезно подумать о разнице между файловой структурой и структурой 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
person akc42    schedule 25.11.2015
comment
Это все равно испортит вулканизацию - person Olivier Langelaar; 29.03.2016
comment
@OlivierLangelaar должен признать, что я перестал беспокоиться о вулканизации, так как я использую http/2 и оставляю все компоненты как отдельные загрузки. Помогает то, что я тоже ленивую загрузку (см. Предпоследний поликаст) - person akc42; 29.03.2016

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

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

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

person Hin Fan Chan    schedule 19.05.2016