Following my last autobiography, I promised to post a story concerning the toughest barriers I faced during testing web components.
The fact is that, when the number of components reaches hundreds, there will be thousands of those obstacles you meet along the way. In this story, I will point out the 10 most common barriers.
In short, CDN offers a fast, efficient and secure delivery of content to websites. To test remotely on sites like CodePen, JSFidde or JSBin, a reliable CDN is heavily needed.
Otherwise, you need to test it locally, which includes downloading the source code, installing the dependencies and serving the demo on the website (I say it's triple, if not more, the amount of work).
Most of the times you will see the HTML imports are either
<link rel="import" href="../google-map/google-map.html">
<link rel="import href="bower_components/google-map/google-map.html">
So, which one is the correct way?
The answer is that they are both correct. When developing locally, bower_components is the folder that contains all of your dependencies. So it is logical to import codes from there, the problem comes when you want to make demos for example on CodePen, there is no bower_components folder because it's only installed locally.
When we stopped to use the CDN and started to use Bower we had this default
bower_components folder commited (which is now called
We made this decision because we want people to be able to demonstrate their elements right from the
gh-pages and debug them easily.
However this causes reusability problems. They cannot be shared with Bower and used by other apps.
Polymer comes up with the relative path serving style to make online and local testing consistent. webcomponents.org CDN also behaves in a pretty similar way. So if you develop a web component using Polymer, always uses the relative path for imports and the command polymer serve for serving.
Even though modern browsers are making progress in implementing Web Components standards, not all the technologies are natively supported. When I was testing, so far only Chrome & Opera supports Web Components natively. The rest of them provide partial support and usually need the polyfill, webcomponentsjs, to make web components function properly.
🚨 Moved to
We are actively working on migrating open Issues and PRs to the new repo. New Issues and PRs should be filed at
It's quite common that developers forget to import the polyfill in the demo. Hence, those samples will not work in any browsers except for Chrome or Opera.
I saw a lot of projects, getting published without a demo and a single word for how to use it. This is exceptionally careless considering the element was created with the author's own way of usage. Most of the time, I have to read the source code and figure out how to use it.
Even though not being official, it's always a good practice to name your main component the same name as your project's. For example, I've met cases where the primary element is named skeleton-layout.html, and the project is named good-component . Those projects leave me extremely confused.
"Testing a product is a learning process" - Brian Marick
The best thing about this journey is that I can learn the mistakes, which often go past the normal eyes, that people make. I have fun along the process, and will all the way again if given a chance.
Here is my last autobiography that I mentioned in the beginning, it’s a 4-min read. Feel free to check it out.
If you have any question regarding testing web components, feel free to PM or send me an email.