Comments (5)
Mixin pattern
The mixin pattern is when your module exports a function that takes a base class to extend. This prevents the dependency on HTMLElement
.
export default function(BaseElement) {
return class extends BaseElement { /* ... */ }
}
We could use this similar pattern while still allowing the element to do its own registration.
export default function(BaseElement, customElements) {
customElements.define('my-element', class extends BaseElement {
});
}
In the client you would have a simple wrapper:
my-element.client.js
import register from './my-element.js';
register(HTMLElement, customElements);
And on the server you would provide implementations of these:
import register from './my-element.js';
class HTMLElement {
// This can be as complex or as simple as the element needs.
}
class CustomElementsRegistry extends Map {
define(...args) {
this.set(...args);
}
}
const registry = new CustomElementsRegistry();
register(HTMLElement, registry);
from community-protocols.
It sounds interesting, but is this really runtime agnostic? I mean for the registration part, yes it does, but it can't prevent developers to pull browser APIs in their web components, so we'll still have to deal with the problem.
I might be missing something (maybe the whole point of the proposal here, please don't be offended, I am not very experienced and not English fluent) but if web components still need to access to global objects like window
or document
then injecting or providing global objects will still be necessary and I think that the Realms API proposal will make it easier to execute a web component in a DOM like context.
To conclude my question is: is it really necessary to require that web components authors should split the implementation and the registration of web components if it only solves the registration issue?
from community-protocols.
@fgirardey This seeks to create a convention for passing dependencies through a registration function, so you could pass any dependency that the element has, not just the HTMLElement
and customElements
objects. An element that is conforming to this convention is doing so on purpose, so we should assume that they will not use browser-specific globals but rather use passed in values.
Would an object as the first parameter be better? That way the provider can pass in as many dependencies as the element has, and then the element can destruct:
export default function({ BaseElement, customElements }) {
customElements.define('my-element', class extends BaseElement {
});
}
Also, #18 was created as a way to shim the global environment without setting browser globals on it, so it's an idea in a similar vein to what you are suggesting. Happy to discuss your idea in that issue.
from community-protocols.
Thank you @matthewp, I have no particular suggestions, I like this injection approach, as a software developer, is perfectly understandable and actually desirable.
But I have concerns about the feasability to make every developers to do so. Obviously this good practice will not be applied by every developer and we'll still have to deal with custom elements that directly use globals.
I am probably too pessimistic but I think that it should be the responsibility of the container to deal with the global issues rather than the contained element.
I've read #18 but I don't see how it will help because the existing custom elements will need to opt-in and use those well-known symbols.
from community-protocols.
Thanks @fgirardey, I'm going to answer your feedback on #18 in that issue.
As for the feasibility of this idea, I agree with you that it's unlikely to sway enough people to adopt this pattern, which is why I started #18 as an alternative. It's worth keeping open a little while longer just in the off-chance that the community would be interested in adopting the idea though.
from community-protocols.
Related Issues (20)
- [pending-task] Cancellation mechanism HOT 1
- [progressive hydration] self hydrating custom elements HOT 4
- Compatibility and Interop Specification (Versioning WCs) HOT 4
- [context] Do we *need* `multiple` and `dispose()`? HOT 5
- [defer-hydration] Requesting hydration of a disconnected component HOT 7
- [context] Fully event driven context protocol HOT 7
- [context] Event namespace HOT 8
- [reactivity] Reactivity/Observable/Signals Proposal HOT 19
- [context] Declarative alternative HOT 1
- [defer-hydration] Async hydration HOT 3
- [context] Some concerns, and an idea of how they could be addressed HOT 16
- [Context] add learnings from the front
- [Proposal] DOM Scope Request Resolution HOT 6
- [Proposal] Registration API HOT 13
- [context] What is the use case for one-off requests?
- [SSR] DOM Shim Specification and / or Polyfill HOT 12
- [slottable-request] Given that `remove` is a short, common identifier, we may want to consider exposing this as a static symbol like `SlottableRequestEvent.remove`.
- [slottable-request] Code examples here would be good.
- [context] Type definitions aren't consistent.
- [context] `createContext` function recommendation
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from community-protocols.