Lit-element: [Feature Request] collect [id] elements in a helper property of a LitElement instance.

Created on 9 May 2020  路  4Comments  路  Source: Polymer/lit-element

I think this has been requested before, I can't find the original post.
Would it be possible to reconsider this request ?

In Polymer $ contains all scoped elements that have an id attribute. Why won't LitElement implement this too ?
If I remember correctly someone suggested to make a wrapper class with a method that will create this global property but when I think about wrapping a class I think something bigger than just implementing such a trivial feature.
Also when using an id attribute on a template's element most of the time it's because this element has a particular functionality and is going to be used here and there in the code, therefore this.shadowRoot.querySelector or @query('...') syntaxes because too tedious to write.

Sometimes it's the small changes that make the big difference, I am probably over 20 projects using LitElement and I feel really tired to always write this part when I'd expect to just use something like this.$.myContainer to designate div[id=myContainer]

Please reconsider this feature. Thanks!

Core Libraries

Most helpful comment

The reasons we left this feature out of LitElement are that

  1. this.$ only works with initially rendered elements - it doesn't work with subsequently rendered content in composed templates from conditionals and loops.
  2. We're trying to keep LitElement as small and as non-overlapping with the platform as possible. We already have a decent way of getting elements from the shadow root with this.shadowRoot.querySelector which importantly works in any web component, not just LitElement.
  3. this.$ doesn't type check, is prone to typos, and hard to refactor because it's so dynamic. You would need a way to declare it's type, which brings us to...
  4. @query() is generally better because you declare (and document if you want) the elements you expect and their type if you use TypeScript. It's on-demand because it queries the live DOM. It supports any selector, and there's @queryAll()
  5. Perf, a little. Setting up this.$ takes work which might not be used. Maybe ids are there for CSS.

All 4 comments

The reasons we left this feature out of LitElement are that

  1. this.$ only works with initially rendered elements - it doesn't work with subsequently rendered content in composed templates from conditionals and loops.
  2. We're trying to keep LitElement as small and as non-overlapping with the platform as possible. We already have a decent way of getting elements from the shadow root with this.shadowRoot.querySelector which importantly works in any web component, not just LitElement.
  3. this.$ doesn't type check, is prone to typos, and hard to refactor because it's so dynamic. You would need a way to declare it's type, which brings us to...
  4. @query() is generally better because you declare (and document if you want) the elements you expect and their type if you use TypeScript. It's on-demand because it queries the live DOM. It supports any selector, and there's @queryAll()
  5. Perf, a little. Setting up this.$ takes work which might not be used. Maybe ids are there for CSS.

I can't argue with that. Thanks to take your time to expose the details.
Also I have to ask, are there any LitElement wrappers in the npm community that the Polymer team would recommend to use when one wants to augment the capabilities of the plain class ? With features like the one I am asking here, debouncer, and other extended features I can't think of right now.

I've seen a wrapper that adds observable fields, and I think Netflix might be working on something with computed properties. I think a mixin to add this kinds of features is definitely a good approach!

Ok. Thanks for confirming. I'll make a mixin as an individual package.

edit: https://github.com/vdegenne/cherry-on-lit

Was this page helpful?
0 / 5 - 0 ratings

Related issues

erikkroes picture erikkroes  路  3Comments

Leon-Alexey picture Leon-Alexey  路  5Comments

quentin29200 picture quentin29200  路  3Comments

kurukururuu picture kurukururuu  路  3Comments

tamis-laan picture tamis-laan  路  4Comments