-
Notifications
You must be signed in to change notification settings - Fork 83
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
feat: expose all DOM level 2 element prototypes #637
Conversation
I exposed all fundamental and extended interfaces according to the specs while keeping the constructors for almost every class private (I think only DOMException, DOMImplementation, NamedNodeMap and NodeList currently don't check for the internal symbol). I didn't add tests for the changes yet as I wanted to ask you how you want to handle this first. Do you want a new file just for testing the constructors or do you want to add a file for each class? Also you mentioned here that you want to expose the classes under "DOM". However I think it would also be fine to just expose them directly, so you can import them like this: import { Document, Element } from '@xmldom/xmldom'; rather than having to import them like this: import { DOM } from '@xmldom/xmldom';
const { Document, Element } = DOM; I think other libraries also just expose them right away, at least I know it this way. Also I forgot to apply the changes to some existing tests… I‘m gonna do that tomorrow 😅 |
Great stuff, will review it in detail later, when the tests are passing. Since we now have an approach for private constructors, there is no need for the DOM namespace. The public constructors that are left now are not an issue from my perspective. Regarding tests: I think I would prefer to have a check for each "class" in the related file. Can even be the first test in each file. Is the symbol is even private for "us", meaning we don't even have access to it in the tests and have to use the DOMImplementation to create them? A last remark: whatever is in the PR description usually goes into the commit message when squash merging. So we should avoid quwstions and instead describe the reasoning behind the changes. Questions can best be put in the comments. Would be nice if you can change that. Thx PS: you don't need to mention me, I'm watching the repo for every change. |
Hey @karfau, |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #637 +/- ##
=========================================
Coverage ? 94.27%
=========================================
Files ? 8
Lines ? 2096
Branches ? 537
=========================================
Hits ? 1976
Misses ? 120
Partials ? 0 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thx
Closes #40.
Exposes all fundamental and extended interfaces according to the specs while keeping the constructors for
Node
,Document
,Element
,Attr
,CharacterData
,Text
,Comment
,CDATASection
,DocumentType
,Notation
,Entity
,EntityReference
,DocumentFragment
,ProcessingInstruction
private by checking a symbol in the constructor.