Skip to content

Conversation

@karlseguin
Copy link
Collaborator

The NodeWrapper pattern attaches a Zig instance to a libdom Node. That works in isolation, but for 1 given node, we might want to attach different instances.

For example, for an HTMLScriptElement we want to attach an onError, but for that same node viewed as an HTMLElement we want to a CSSStyleDeclaration. We can only have one. Currently, this code will crash if, for example, we create the embedded data as an HTMLScriptElement, then try to read the embedded data as an HTMLElement.

This PR introduces dedicated state class. So if you want the onError property, you no longer ask the NodeWrapper for an HTMLSCriptElement. Instead, you ask for a storage/HTMLElement.

Nothing fancy here, just memory-inefficient optional fields. If it gets out of hand, we'll think of something more clever.

The NodeWrapper pattern attaches a Zig instance to a libdom Node. That works in
isolation, but for 1 given node, we might want to attach different instances.

For example, for an HTMLScriptElement we want to attach an `onError`, but for
that same node viewed as an HTMLElement we want to a `CSSStyleDeclaration`. We
can only have one. Currently, this code will crash if, for example, we create
the embedded data as an HTMLScriptElement, then try to read the embedded data
as an HTMLElement.

This PR introduces dedicated state class. So if you want the onError property,
you no longer ask the NodeWrapper for an HTMLSCriptElement. Instead, you ask
for a storage/HTMLElement.

Nothing fancy here, just memory-inefficient optional fields. If it gets out of
hand, we'll think of something more clever.
Copy link
Contributor

@sjorsdonkers sjorsdonkers left a comment

Choose a reason for hiding this comment

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

Could consider not making the optimization of defining multiple State structs and just use 1 for everything. So combine Document and HtmlElement state structs as well for now.

@karlseguin
Copy link
Collaborator Author

Could consider not making the optimization of defining multiple State structs and just use 1 for everything. So combine Document and HtmlElement state structs as well for now.

Actually, I think we have no choice. With the way I did it, we'll still run into the same problem as soon as we need something on both HTMLElement and Element or Node.

I've added a global State. This has the benefit that we can use a MemoryPool(State) which gets re-used between pages.

@karlseguin karlseguin merged commit 8de57ec into main Jun 4, 2025
11 checks passed
@karlseguin karlseguin deleted the pozo_for_custom_state branch June 4, 2025 13:38
@github-actions github-actions bot locked and limited conversation to collaborators Jun 4, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants