Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use new webidl2js bundle-entry.js feature #2092

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

TimothyGu
Copy link
Member

@TimothyGu TimothyGu commented Dec 25, 2017

Uses the feature introduced in jsdom/webidl2js#101. Skipping CI for now as the change has not yet been merged, much less published, in webidl2js.

The result is a beauty.

[ci skip]

@@ -1,5 +1,6 @@
[Constructor,
Exposed=Window]
Exposed=Window,
LegacyWindowAlias=HTMLDocument]
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this might no longer be correct because of whatwg/html#4792.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well whatwg/dom#551 was closed, so this change should be reverted.

@Zirro
Copy link
Member

Zirro commented Dec 27, 2017

This looks like a great improvement over the previous code. The comment you added makes me wonder, though...

the "core" here is the "extraDOM" object imported from living/index.js, not the core tied to a specific Window

Maybe we could take this as an opportunity to give these objects names that better clarify their purpose?

While I'm familiar enough with the codebase to know what they are, having two different core's (and something named extraDOM) is probably not the most obvious naming for new contributors.

Perhaps the core-names are no longer appropriate for the code as it is currently structured at all?

EDIT: ...seeing how many locations the core naming is being used in though, this might be a discussion worth its own issue.

@TimothyGu
Copy link
Member Author

@Zirro I wholeheartedly agree.

I plan on coming back to this after getting #2088 merged (review welcome!). I'll also think of how to integrate some good parts from my TimothyGu/jsdom:vm-hah branch, as this change (and the whole bundle-entry.js concept) originated from that branch, though the full clean-globals-for-every-Window probably feature will probably come after this PR is merged.

@Sebmaster
Copy link
Member

So we're still sharing prototypes with this change, but have a proper window object in all class instances?

@TimothyGu
Copy link
Member Author

No, this doesn’t change the status quo regarding that: all prototypes are shared, most classes are window-agnostic. It only simplifies the code as it is. The passed window is for the few webidl2js-enabled interfaces that require window to be known. But yes, this API is what I expect how window-specific prototypes will eventually look like.

}
this._core = dom;
// TODO move this somewhere else.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Running this on every window initialization seems sad since it's all a shared object.

@@ -36,14 +33,14 @@ const WindowEventHandlersImpl = require("../living/nodes/WindowEventHandlers-imp
// NB: the require() must be after assigning `module.exports` because this require() is circular
// TODO: this above note might not even be true anymore... figure out the cycle and document it, or clean up.
module.exports = Window;
const dom = require("../living");
const bootstrapDOM = require("../living/generated/bundle-entry").bootstrap;
const extraDOM = require("../living");
Copy link
Member

@domenic domenic Jan 22, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like us to carefully consider our names here. E.g. instead of "extraDOM", maybe "nonGeneratedInterfaces" or similar.

Similarly, instead of "bootstraDOM"... what? What does this function do? It's not clear to me.

Copy link
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Excited about getting all these things generated; would like to clean up the names while we're at it.

@@ -81,7 +90,7 @@ function Window(options) {

// List options explicitly to be clear which are passed through
this._document = Document.create([], {
core: dom,
core: this._core,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't be necessary after #2098.

@@ -60,15 +57,27 @@ function Window(options) {
///// INTERFACES FROM THE DOM
// TODO: consider a mode of some sort where these are not shared between all DOM instances
// It'd be very memory-expensive in most cases, though.
for (const name in dom) {
this._core = bootstrapDOM("Window", window, { window });
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We no longer store _core on Window after #2098. Not sure how that fits in here.

@@ -355,6 +355,8 @@ const mappings = {
}
};

// N.B. the "core" here is the "extraDOM" object imported from living/index.js, not the core tied to a specific Window.
// Thus, it only contains the limited set of objects in living/index.js, but that is enough currently.
module.exports = core => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just update the parameter name then, instead of creating a comment explaining why it's misleading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants