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?

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.