Skip to content

refactor Document, element, and related files#287

Open
jderochervlk wants to merge 12 commits into
refactor-locationfrom
refactor-document
Open

refactor Document, element, and related files#287
jderochervlk wants to merge 12 commits into
refactor-locationfrom
refactor-document

Conversation

@jderochervlk

@jderochervlk jderochervlk commented Jul 8, 2026

Copy link
Copy Markdown
Collaborator

This one is larger than the previous PRs, but it builds on the same ideas.

I don't love DOMTree, but I needed a spot to store types that are used across other modules without increasing the size of DOM. If I can get DOM down more I might remove this later.

Main changes:

  • Adds new DOM structure modules to the build: DOMTree, HTML, and SVGElement.
  • Moves many types out of the old broad DOM/DomTypes style into more specific modules:
    • Core tree types use DOMTree.node, DOMTree.element, etc.
    • HTML element types use concrete modules like HTMLImageElement.t, HTMLVideoElement.t, HTMLCanvasElement.t.
    • SVG image references move to SVGElement.svgImageElement.
    • Shared non-tree DOM types remain under DOM, like DOM.domRectReadOnly, DOM.canvasRenderingContext2D, DOM.videoFrame, DOM.fileList.
  • Shrinks src/Base/DOM.res by extracting large chunks of element/node/document-related structure into dedicated files.
  • Refactors APIs across Canvas, Window, IntersectionObserver, ResizeObserver, UIEvents, WebAudio, EncryptedMediaExtensions, XPath, and tests to stop depending on DomTypes.
  • Moves some formerly separate *Types definitions directly into their owning modules, notably MutationObserver, and deletes MutationObserverTypes.res.
  • Updates tests and unmonorepo rewrite expectations to point at the new module locations, for example Element.t instead of DomTypes.element.

@jderochervlk jderochervlk changed the title refactor Document and related files refactor Document, element, and related files Jul 8, 2026
@jderochervlk jderochervlk marked this pull request as draft July 8, 2026 19:29
@jderochervlk jderochervlk marked this pull request as ready for review July 8, 2026 21:26

@brnrdog brnrdog left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I liked the types living within their interfaces, makes them much more discoverable than before with the DOMTypes. I think the DOMTree is fair given the recursive types.

I'm just missing a .t for Element/Node/HTMLElement, like we do for other modules. What if we add a small alias on each like:

type t = DOMTree.element
include Impl({type t = t})

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.

2 participants