December meeting availability and agenda #104
Comments
|
Agenda items that I know some people are interested in, if we chose to include them:
What would you want included? |
|
Do we have an established community convention for |
|
@davatron5000 happy to include this in the convo. Is there any additional background that the community should take into account in advance? |
My own concern is with respect to subclassing. Consider that an element makes a private My straw proposal is something like this: static internals = Symbol();
constructor() {
super();
const {internals} = this.constructor as typeof MyElement;
this[internals] ??= this.attachInternals();
} |
|
That’s an interesting approach @sorvell. If this lines up with your thoughts (shape wise) @davatron5000, would it make sense to get an issue or PR into https://github.com/webcomponents-cg/community-protocols (as the user of |
|
Great discussion today! Thanks to all of your for making 2024 an amazing year for Web Components. 🙇🏼♂️ Let's do it again in 2025 👏🏼 👏🏼 👏🏼 Action Items
Meeting chat inside...You |
I've touched on this before in various GitHub issues (probably search my username name and attachInternals together) but basically the issue is we don't have To solve this issue, the simplest proposal I could think of is making I'm assuming that this is possible with unique coordination with the JS engine in a way that JS cannot polyfill it currently (although I've asked for the ability to TC39 before, see below). With this concept in place it would become class SomeFrameworkBaseClass extends HTMLElement {
#internals
constructor() {
super()
this.#internals = this.attachInternals()
}
connectedCallback() {
// Access internals without it being leaked to public
this.#internals
}
}A subclass would then be able to easily get internals too: class MyEl extends SomeFrameworkBaseClass {
#internals
constructor() {
super()
this.#internals = this.attachInternals()
}
connectedCallback() {
super.connectedCallback()
// Subclass can also use it!
this.#internals
}
}Currently, the previous code sample will throw a runtime error. This idea would fix that. People on the public usage side would not be able to get the internals: const el = new MyEl()
el.attachInternals() // runtime error: cannot call attachInternals outside constructor.
el.#internals // syntax errorThere's no way to exactly implement this concept in plain JS, it would require a mechanism that can only be implemented on the native side, but we can kind of emulate it to a certain extent: class HTMLElement {
#isConstructing = true
constructor() {
queueMicrotask(() => this.#isConstructing = false)
}
attachInternals() {
if (!this.#isConstructing) throw new Error('Can only call attachInternals in constructor')
return theInternals
}
}
// User code:
const el = new SomeEl
el.attachInternals() // this currently does not error with the example, but the native version would
setTimeout(() => {
el.attachInternals() // throws
})Here are some ways to do this natively:
With this pattern the internals would still be easy to access from the public side: import {Base} from 'some-lib'
const el = document.querySelector('some-el') // some el that extends from Base
const internals = el[Base.internals] |
Please share you availability here to support scheduling out December meeting. The timing is a little different than we've had in the past as I'll be working "remotely". If that causes issues, I'm happy to pass the chairperson duties to someone else for the month if we'd really like to get a session in. 🆓
Don't forget, all WCCG events are listed on this calendar. 📆
As a reminder, we chat between meetings in Discord, where we'd love to hear from you. 🗣️
If there are other topics you'd like to discuss, breakouts you would already like to have scheduled, or anything else, please drop your thoughts in the comments below! 🙇🏼♂️
The text was updated successfully, but these errors were encountered: