How to structure large Polymer projects with 100+ elements

Question

The Polymer Starter Kit is a good reference to start a Polymer project. You simply put all your elements into the app/elements folder. This works pretty neat for small to midsize projects.

It becomes messy when you have more than ~30 elements. Then you want to refactor the flat elements folder into a deeper folder structure like this one:

- 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 ---- ...

There are a couple of issues:

• when you want to demo and test submodules you need to import all dependencies above every element definition
• you break the pattern of "all elements are siblings"
• your relative paths become messy (lots of ../../../my-module-x/my-module-y)
• you either have lots of paths like ../../../../bower_components or you use /bower_components, then you need to have a redirect in your dev-server and the absolute paths will mess up gulp-vulcanize.
• With a demo and test folder for every element your directory structure grows very quickly

Here is a nice article describing the problem and pointing out two solutions:

• Separate Elements Repository
• Building Reusable Elements

Separate Elements Repository like in the Topeka App works for ~30 elements, but once you are up to 100+ elements, you run into the same issues.

Building Reusable Elements seems like a good idea at first, because you can encapsulate everything nicely. But working on hundreds of repos is painful, and the standard pattern breaks when you want to have more than one single element in your repo.

So I am wondering, what are good practices on how to build large Polymer apps? Are there any examples of projects with way more than 30 elements?

What are good practices for reusable elements repos that contain multiple elements?

What is a good structure for multiple entry points?

In general: How do you scale Polymer projects?

Sechrist

Not really any help to your current issue. But I watched some of the PolymerIO videos, where they spoke about plans to ease the use of including dependencies (maybe auto-import the needed dependencies?). In other words, even if it's a problem for you at the moment, it might be a lot easier in the "near" future. :) – Dory

You probably mean Polygit ? "The Magic Server serves files directly from github". It makes it a little easier to have multiple repos (since you do not need to do a bower update after every change), but you would still need to commit to 100s of repos if you follow the standard Reusable Elements approach... – Sechrist

Answer 1

We have a production application serving up 100's of elements. We found it useful to group multiple elements inside folders to cut down on the number of repos and folders. We still make all elements siblings.

There is a bit of precedent for this inside Google's own elements. If you take a look at app-layout and polymerfire, they both contain multiple custom elements.

The mind shift is to remember that not every element should exist in it's own directory.

Sidwell

Answer 2

It is useful to your issue to think about the difference between the file structure and the url structure. Making the web server map the files to the same place. This is what polyserve does, and you can configure wct to set up its server like it too.

So, for instance, when you are creating a single element to test, its normally sitting directly in the project directory, but the web server is mapping this parent directly directly into /components. Its doing the same with bower_components, so they appear at browser level to be at the same place. That is why references like ../polymer/polymer.html work

I'm thinking in the scenario you propose above, that you repeatedly do something similar at each submodule level so that each element can reference polymer, or its other web components at ../polymer/polymer.html

The net result would be an overall project "URL" structure that looked like

-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

Rudin

This will still mess up vulcanize – Agrigento

@OlivierLangelaar must admit I have given up worrying about vulcanize, as I use http/2 and leave all the components as separate loads. Helps that I lazy load too (See last but one polycast) – Rudin

Answer 3

IMO the key to organize Polymer elements goes all the way to designing the solution to problems / pages. Think of designing Lego pieces for a particular model. Yes, you can build many pieces that have very specific functions, but it will be better to focus on re-usability and design fewer pieces that will cover most of the structure (base elements) and then add some touch up pieces (touch-up elements) to finish the model. Base elements should be simple and very generic.

While the touch-up elements are not likely to be recycled, they can stay with the page. Base elements on the other hand should be placed in a folder very close to the root with very descriptive names. As development progresses, the rate of new base elements will decrease as well as time needed on developing new pages.

If the design is correct, then how you categorize elements doesn't matter, just to place them in the bower_components folder unless you are building public polymer elements. Everything in bower_components should be controlled by bower.json so you will delete the whole folder and use bower install to re-populate it.

Providenciaprovident