Expose DOM Level 2 Elements

[esbullington]

Glad you all have forked and are maintaining xmldom, thank you!

There were several issues in the old unmaintained repo dealing with exposing DOM Level 2 object interfaces, such as Node, Element, NodeLike. Right now, those classes are private.

There are multiple library that deal with the browser DOMParser that make use of these for things like instanceof checks. As one example, I'm using bs-xml, which wraps DOMParser for Bucklescript/ReasonML, and which has to check if an object is a Node or Element.

Would you be open to a very simple PR that exposes those classes? Specifically, the ones listed as fundamental interfaces in the Level 2 DOM Core spec?

DOMException
ExceptionCode
DOMImplementation
DocumentFragment
Document
Node
NodeList
NamedNodeMap
CharacterData
Attr
Element
Text

[esbullington]

To clarify my issue, I can submit a PR, just wanted to make sure you're open to a PR for this issue. Looks like yes based on the labels. Thanks!

[brodybits]

Thanks, yes. Added to intermediate milestone before 1.0.0 for now (see milestones here). Unfortunately I do not have much time right now to review and merge contributions right now, hope another maintainer will have a chance.

[cortopy]

I'm also caught by this issue. My workaround is to rely on typescript types for the dom:

function isAttr(attr: any): attr is Attr {
  return attr.constructor.name === 'Attr';
}

[cortopy]

Actually, ignore my workaround. I was just hit by a bug in production code, as minified code will change the constructor's name (it's a private class after all) and the check won't work

[karfau]

Sorry for joining the conversation so late, but there is one issue that we need to be aware of:
The DOM spec(s) only define interfaces for those things, but we can only expose the classes.
So it means that by exposing them we "risk" that somebody starts using the constructors of those classes.

If somebody knows how to "mark the constructors as private" or how other projects do that, please let us know.
I could imagine to only expose them in a "namespace"which could also be the DOMImplementation, since it's meant to be used to actually create instances of Documents "manually".

So we would only export DOMImplementation and it would provide access to all the "interfaces" so you could say:

const doc = new DOMParser().parse('<xml/>');
if (doc instanceof DOMImplementaiton.Document) { // true

If DOMImplementaiton is "to long/unpractical" we could export a (read only) object called DOM,
which provides the same access, so it would just be

if (doc instanceof DOM.Document) {

Since we are planning to move the types definition into the repo, based on the actual doc comments and types present in this code base (see #191), we might also be able to mark the constructors as @private and "only export the interface" this way...

What do you think?

[danmichaelo]

...

So we would only export DOMImplementation and it would provide access to all the "interfaces" so you could say:

const doc = new DOMParser().parse('<xml/>');
if (doc instanceof DOMImplementaiton.Document) { // true

If DOMImplementaiton is "to long/unpractical" we could export a (read only) object called DOM, which provides the same access, so it would just be

if (doc instanceof DOM.Document) {

Since we are planning to move the types definition into the repo, based on the actual doc comments and types present in this code base (see #191), we might also be able to mark the constructors as @private and "only export the interface" this way...

What do you think?

That would be lovely! I just found myself with the same need. I think both would work fine and don't have a strong preference – a longer name like DOMImplementation is fine if you want to indicate that this is something most users won't need, but DOM is also very neat.

[karfau]

The priority for this is very low at our end, but if somebody creates a PR with one of the two solutions we will follow up on it.
If someone is even up for finding a solution for "private" constructors, which can still be used inside the module they are created in, please propose some code snippets here before investing time into a PR.

[kpalatzky]

@karfau In general i do have two aproaches in my mind to make the "constructor private":

Use of inheritance:

It would be possible to implement the "Interface" empty without a logic e.g. "Node" and additionally a "NodeImpl" which inherits from node and contains the logic. Only the "Node" but not the "NodeImpl" is exported. This allows you to check the node, but not create a new one.

Simple Example:
https://jsfiddle.net/kpalatzky/vb6m9urw/5/

Use of symbols:

A symbol is passed in the constructor, which is compared with an "internal symbol". If it is not the same, an error is thrown.
The internal symbol is not exported, so the constructor remains "private".

Simple Example:
https://jsfiddle.net/kpalatzky/vb6m9urw/8/

What do you think?

[Ponynjaa]

@karfau I would be down to implement any of the two suggested approaches mentioned by @kpalatzky
Just tell me which you prefer. We really need these for our typings. Would be great for 0.9.0.

[karfau]

If the internal symbol solution is possible in ES5, it sounds like that is the solution which requires less code and is easier to follow.