This repository has been archived by the owner on Mar 13, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 42
Content element selectors - loosen up please! #45
Comments
A concrete example that demonstrates how you want to use this would be interesting. |
I have been fighting the framework all day yesterday trying to achieve some simple composability via content but completely ran into this wall posed by current limitations and by there not being proper ways to extend from a custom element. Your thoughts, suggestions are most welcome :) |
Currently playing with and proposing this minor enhancement in Polymer core which would give me a lot of leverage to achieve this. https://github.com/Polymer/polymer/blob/master/src/lib/polymer-bootstrap.html#L72 // notify registration
Polymer.registered(prototype);
// public API on instance
// return {
// }
})();
// allow developer to override this callback
// to add custom functionality
Polymer.registered = function(prototype) {
};
// look up a previously registered element by name
Polymer.findRegistered = function(name) {
return Polymer.telemetry.registrations[name];
}; |
After spending 3 hours on this I'm utterly unable to even figure out how to expose |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
As I understand it and from own experience, a content element can only select direct children. This makes sense in most simple scenarios, but as soon as you have a custom element in the mix it falls apart. The custom element acts as a wrapper around the "real" child elements, now in the shadow dom, but then the children are not there for selection and you can't really compose this way with custom elements which should be the whole point?
Am I missing something here!? I can't believe this design constraint.
https://github.com/Polymer/core-selector/blob/master/core-selector.html#L292
IMO, the
nodes
should be mapped, so that if a node is a custom element, it should add its children to the list of nodes as well (only at the top level, not recursively!). I understand why you have the current limitation, but sometimes (often), the custom elements acts as a wrapper, a structural element container without any (intended) UI influence, just a way to decompose a logical entity.PS: How do you test if a given node is a custom element? Simply by naming convention? or is there a better way? Thanks.
The text was updated successfully, but these errors were encountered: