Best practices for reusable component development.

[hourliert]

Hi,

First of all, thank you very much for this seed. It is wonderful and very useful.

I am new with polymer and I am trying to setup a good environment to develop a web app. Firstly, I want to develop a reusable login-form component. It will depend on paper-material, paper-input and paper-button elements. I used this seed to create it.

Very quickly, I have noticed that developing in this seed-element project was not easy. There are no files watchers for polyserve reloading and no watchers to trigger wct tests (I hope a watch mode will be added to wct soon: Polymer/web-component-tester#32).

What is the best practice to develop a reusable component ? Should I include a git submodule directly in my webapp and use the webapp files watchers ? Should we add a watcher mode into polyserve ? Anything else ?

Thanks in advance.

[hourliert]

I find a solution to have tests reloading + browser reloading with polyserve. I use browsersync as proxy between the browser and polyserve. It works great.

I did a little gulpfile with some useful tasks. I could share it if needed.

[notwaldorf]

@arthurevans Is there a place where we can put this sort of info in the docs?

[JohnRiv]

Polymer Team - what is your process for propagating updates to this seed-element to all of your other elements?

[ebidel]

What do you mean?

On Fri, Oct 23, 2015, 6:48 AM John Riviello notifications@github.com wrote:

Polymer Team - what is your process for propagating updates to this seed-element to all of your other elements?

— Reply to this email directly or view it on GitHub https://github.com/PolymerElements/seed-element/issues/53#issuecomment-150577959 .

[filaraujo]

Well taking seed-element as the basis for our components. If each element is incapsulated with its own tests, demo pages and assets, how do you maintain a jslint, jscs, process against those repos? Doesn't seem that each element gets its own testing setup, which leads us to believe that is managed by an external repo/process/submodule/whatever.

[ebidel]

The Polymer team has a CI runner that runs tests against all of our element repos. That's particular to our case where we're vending 100s of resuable elements. Unless a developer using seed-element is doing the same, I'm not sure that's a problem they'll run in to. wct can be used for individual project setups.

Note sure if this is what @JohnRiv was after though...

[JohnRiv]

Thanks for the reply @ebidel. To give more context of where we're coming from, we have one project with just under 200 custom components we created ourselves, and that project has lots of coding standards enforced via jshint, jscs, etc., as well as additional tools to run tests via wct, gather coverage info via web-component-tester-istanbul, etc. So in that project, whenever we want to add a new tool to assist in the development process, we do it in one spot in the project, and then all the components benefits because they're all built directly into the project

Recently, we've begun the process of pulling some of those components out into their own repos and hosting them internally so other projects can use them (we've done that for about 10 so far). We have our own seed element that includes tools for running these coding standards on developer's machine and our CI environment, but if we make a change (for example, the usage of web-component-tester-istanbul is very recent), we add that to our seed element first so any new elements created will have it, and then we have to manually add that to each component, which is obviously not maintainable.

I was considering creating our own version of load-common-gulp-tasks and making that a dependency for all of our polymer repos, but would prefer to borrow from what you're doing. So it sounds like we should take a deeper look at ci-runner and how we can integrate that into our CI environment?

[ebidel]

@azakus is our expert there. I'm afraid I don't know much about our setup.

[filaraujo]

thanks eric

[dfreedm]

FWIW, I'm actively trying to deprecate our homegrown CI Runner for Travis CI to use more standard tools.

I've written up a sample config you can copy/paste into any element you want to test on Travis CI: https://github.com/Polymer/tools/tree/master/travis

[JohnRiv]

Thanks @azakus, that's helpful. Do you have a plan for how you'd integrate other tools with that (e.g. polylint, JSHint, JSCS, etc.) to enforce coding standards among all of your components? Or is that still something you're working through?

[dfreedm]

Still working on that, but since Travis CI considers a test failed if any program's exit code is >0, you can just chain them in your config: jshint *.js && polylint my-element && wct

[dfreedm]

Or, use separate lines in the travis.yml

script:
- jshint *.js
- polylint
- wct

[JohnRiv]

true, and then I guess configuration can be explicitly set in the travis.yml script, as long as each tool offers that option (as opposed to setting those in package.json or a .rc file, all 3 methods JSHint supports, for example).

Either way though, the one piece I'm still missing (that you may be working out as well) is how you're going to propagate changes to travis.yml to all of your Polymer repositories if you want to make a change, since Travis expect that travis.yml file to live in the root of each repo.

[dfreedm]

@JohnRiv, @rictic has been working on a tool, tedium which will make a whole bunch of automated changes to our elements. It's still pretty early, but it is already making automated cleanup PRs for us.

[JohnRiv]

Thanks for the info! I'll explore what's going on with that.

[notwaldorf]

@justinfagnani Please tie this feedback back into the tools planning we're doing. Thanks!

[MeTaNoV]

After listening to the last Web Platform podcast, I think it would be nice to have a complete tooling set that enforce the Gold Standard.

[justinfagnani]

One of the questions here is how to see changes from one element to another while developing. My workflow uses only bower and polyserve. bower link from the reusable element repo you're working on, then bower link my-element and polyserve from the repo you're testing in. All changes made to my-element will be immediately visible in the other repo.

[MeTaNoV]

can save some time indeed...

[slanted]

@justinfagnani, @notwaldorf, @robdodson this is how I figured this would be done. It's how we work in npm.

However if a team is all in on polymer and produces 200 elements like @JohnRiv 's team - then bower link will become very tedious in some circumstances won't it?

For example, suppose you want to produce a non-trivial component. Let's call it: <my-checkout></my-checkout>

This element will be similar to the checkout page that you guys developed on the polymer shop app, except that I want to be able to share this my-checkout element with several apps that have a checkout function at the end.

So client apps 1,2, and 3 want to just drop my-checkout on one of their pages and then the my-checkout element goes and gets shipping info, sets payment info, displays offers, lets you review the order and then displays a confirmation page.

Suppose that my-checkout has 50 dependencies (groups of shipping elements, payment elements, configuration elements, product elements, etc...). Does the developer then go to 50 folders and type: bower link, and then in the my-checkout folder type bower link <dep>? That's 100 commands to type to setup your project for development.

I don't want to over dramatize this. But this is how our teams would work. The checkout element has all of those dependencies, and if there is a bug or change needed in the shipping element or a product element, the developer just wants to edit that element, and reload the page and see the change integrated into the my-checkout element that uses those elements.

Some ideas to solve it:

1. I suppose that you could scripts this. But if I now have a <anonymous-checkout> or <simple-checkout> element that has different dependencies (again, around 50), then those scripts would be slightly different and if more elements are coming in that script would need to be updated...seems like a poor development workflow.
2. I could put more elements into groupings/repos. Like: shipping, payment, products. Then it would maybe be 4 or 5 bower link commands X2 so cut it down to around 10.

But I'm wondering if the polymer cli team has any help for a development scenario like this. I know this post is a little old- maybe you guys have evolved on the bower link suggestion? Thanks for all of your work on this. It might be cool to have a 'polymer link-all' command or something along these lines.

And sorry if you've given an answer for this scenario somewhere else, I just haven't seen it yet.