Image credit: thoughtsofascent

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.

No reliable content delivery network (CDN)

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

Import links for dependencies are inconsistent

Most of the times you will see the HTML imports are either

<link rel="import" href="../google-map/google-map.html">

or

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

How to make elements reusable through Bower #11

zenorocha posted on Mar 20, 2014

When we stopped to use the CDN and started to use Bower we had this default bower_components folder commited (which is now called lib).

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.

View on GitHub

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.

People usually forget to import the polyfill

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.

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.

No demo or documentation

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.

Naming convention is important

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.

Final word

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

• For more news and writing pieces on Web Components, follow me on Twitter @binhbbbb
• If you would like to try out Web Components, check out the series Web Components Wednesday, where I introduce and explain easy-to-use web components to beginners.