Say I want to include some credit card input in my page. So, browsing the new Polymer 1.0 elements catalog, I chose the <gold-cc-input> element.
But, I don't like the idea of "Gold", "Platinum" and "Neon" namespaces in my element's name. Is there a way to create aliases for components so in my code I'll be able to use an arbitrary name and use it instead (like <my-cc-input>)?
In Polymer 0.5, you can do this by extending an element. But since Polymer 1.0 is a complete rewrite, the ability to extend a native element is still there, sans extending custom elements. You can read about it here.
Related
Some people seem to like to rewrite
<div id="homepage">[...]</div>
as
<app-homepage>[...]</app-homepage>
Are there any technical or spec related reasons not to do this? Mind that I am talking purely about changing this on the level of the HTML and CSS; The elements have not been defined using the custom elements API.
Tl;dr: Don't do it. Use the custom element spec for what it's made for. Hacking together your HTML syntax is not what it's made for.
Semantics
First of all custom elements in general can break up the semantics of the DOM structure. When custom elements are used properly you receive a lot of power in return, but in this way you give up semantics without any benefit. Instead use the proper HTML5 elements like <header>, <article>, etc.
Undefined custom element state
According to the custom elements spec such elements have a custom element state of
"undefined" (not defined, not custom)
Now, the way the HTML spec works any element which isn't recognized has a defined behavior of create just a default undefined HTML element instance.
Up till the custom element spec it was incredibly dangerous to define such elements because there was a risk that a future version of HTML would implement it, but now all elements with a - are reserved for custom elements.
Does that mean that you are entirely safe? No, because you put yourself in the same namespace as all other custom elements. And unlike with external stylesheets there is no proper way to namespace them, so if you wish to do something like this you will have to write code like
<my-app-name-homepage>[...]</my-app-name-homepage>
and even then you still end up with an element with an undefined state.
I want to validate a custom polymer element. To do this, I want in javascript to access all my nested polymer elements to see if they are valids.
I can't find an easy way to do this.
this.querySelectorAll does not find my inputs that are nested in other polymer elements. It seems I can't use "/deep/" in these selectors.
Is there an easy way to do this ? Or do I have to do a recursive javascript methods that will call a querySelectorAll in all elements with shadow roots ?? (I guess performances will get ugly...)
Thanks for your help.
If there is no fast solution, I will probably try the other way around (have my inputs register to the parent)
Answer:
element.querySelectorAll() will find some elements when using /deep/, however, it only goes so far (1 shadow dom level). This would indeed necessitate recursive calls from each ElementNode.
Note:
This type of behavior largely goes against the core tenets of HTML (i.e. that the web page works no matter how well-formed the content is). In other words, all elements are valid no matter their placement.
As an example, I have made a custom element that only renders specific child elements and hides all others. This still keeps in line with the above tenet, as an element's base rendering is controlled by the element/agent, but allows for the developer/designer to customize its presentation aside from the standard presentation.
For example, lets say we want to do querySelectorAll('canvas') to get all canvases in the document, including the ones in the shadow dom. Is that possible with polymer?
No. For a period of time there was a proposal whereby you could use the /deep/ combinator, but it was found to be bad for encapsulation and has been deprecated. Code that relies upon it will break.
Instead, if you need to, you can take an element and look into its shadow root specifically and query within it.
I know there is this question on multiple inheritance/composition. However, it seems like this question is more about how to reuse functionality from multiple existing elements in other elements. And obviously, the solution for that are mixins.
I would like to know, how I can actually "decorate" existing elements without really borrow functionality from them. We know there is this extends property one can use to extend an existing element with Polymer.
So making a normal <button> behave like a mega-button is as simple as attaching <button is="mega-button"> and write a component for it. But it turns out, that it's not possible to extend multiple elements. So something like extends="foo bar" doesn't work. What if I want to build a web component, that can actually be applied to different elements?
For example, I don't want to only extend <button> elements with mega-button but probably also an <a> element so that it looks like and behaves like a mega-button too?
The mixin approach doesn't really help here (as far as I get it), because they do nothing more then providing shared logic for different web components. That means, you create multiple components, and reuse logic (packed in a mixin) from a mixin.
What I need is a way to create one web component that can be applied to multiple elements.
Any idea how to solve that?
UPDATE
Addy answered with some approaches to handle that use case. Here's a follow up question based on one approach
How to find out what element is going to be extended, while registering my own in Polymer
And another one on Is it possible to share mixins across web components (and imports) in Polymer?
UPDATE 2
I've written an article and concludes my experiences and learnings about inheritance and composition with polymer: http://pascalprecht.github.io/2014/07/14/inheritance-and-composition-with-polymer/
If you need to have just a single import that has support for being applied to multiple elements, your element could include multiple element definitions which may or may not take advantage of Polymer.mixin in order to share functionality between your decorating elements.
So pascal-decorator.html could contain Polymer element definitions for <pascal-span> and <pascal-button>, both of which mixin logic from some object defined within pascal-decorator.html. You can then do <button is="pascal-button"> and <button is="pascal-span"> whilst the logic for doing so remains inside the same import.
The alternative (if you strictly want to do this all in one custom element, which imo, makes this less clean) is to do something like checking against the type of element being extended, which could either be done in the manner you linked to or by checking as part of your element registration process.
In general, I personally prefer to figure out what logic I may need to share between elements that could be decorated, isolate that functionality into an element and then just import them into dedicated elements that have knowledge about the tag (e.g <addy-button>, <addy-video> etc).
I'm writing a <my-codeblock> element, in which I'd like to strip leading and trailing whitespace from the content. Of the polymer lifecycle events, which is the best to use to traverse the contents of the custom element and modify them?
I definitely want to get the modification done before the first paint, and it would be nice to help the polyfill/browser avoid extra work when distributing the nodes I'm going to modify into the shadow dom.
Ironically, I'm working on this exact element as we speak :)
attached() is typically the best place to access light dom children, parent elements, or interrogate distributed nodes. From the faq:
How do I access the DOM in a <content>?
Why do elements report zero (light DOM) children at created/ready time
When is the best time to access an element’s parent node?
Something that hasn't made it to the documentation yet is the domReady callback. If you add domReady to the element, Polymer calls it when the element's initial set of children are guaranteed to exist. If you need to handle dynamically added/removed children, add a Mutation Observer.