I'm a fan of Open Source and have a growing interest in serverless and edge computing. I'm not a big fan of spiders, but they're doing good work eating bugs. I also stream on Twitch.
Basically going with the non-null assertion operator in almost all places, because as mentioned in github.com/sindresorhus/refined-gi..., the assumption with the extension is that the DOM nodes referenced in most cases are expected to be there. If they aren't, the extension breaks, a bug is filed and it's fixed.
One thing to note @bfred-it, is currently dom-chef types need to handle JSX (Element and IntrinsicElements) or we import @types/react.
I'll restate what I tweeted as I probably should have posted my question here originally.
The NamedNodeMap interface in lib.dom.ts does not allow for a string indexer, even though vanilla JS supports this in browsers, e.g. someDomElement.attribute['aria-label'].value.
We have code like this in the Refined GitHub extension, so for the time being, I've gone ahead via a declaration merge for NamedNodeMap
interfaceNamedNodeMap {
[key: string]:Attr;
}
I can't tell from the MDN docs for NamedNodeMap if it's standard or not. All they seem to mention is "Attr nodes' indexes may differ among browsers" which wouldn't apply to access by the attribute name.
Just wondering if this was omitted by mistake or is it because this is not considered WHATWG DOM standard? I went to dom.spec.whatwg.org/#interface-nam... and unless I'm reading it incorrectly, I believe it states that using a string indexer is valid.
This week, I got a PR merged that I've been working on for quite a while for the Refined GitHub browser extension. Feels pretty good.
Basically going with the non-null assertion operator in almost all places, because as mentioned in github.com/sindresorhus/refined-gi..., the assumption with the extension is that the DOM nodes referenced in most cases are expected to be there. If they aren't, the extension breaks, a bug is filed and it's fixed.
One thing to note @bfred-it, is currently dom-chef types need to handle JSX (Element and IntrinsicElements) or we import
@types/react.In the process of working on that PR, I discovered a bug in the TypeScript types that ship with TypeScript.
For context, see github.com/sindresorhus/refined-gi..., specifically this commit, github.com/sindresorhus/refined-gi....
Also, just posting my tweet about this so that people can find discussions about the issue. See twitter.com/nickytonline/status/11...
I'll restate what I tweeted as I probably should have posted my question here originally.
The NamedNodeMap interface in lib.dom.ts does not allow for a string indexer, even though vanilla JS supports this in browsers, e.g.
someDomElement.attribute['aria-label'].value.We have code like this in the Refined GitHub extension, so for the time being, I've gone ahead via a declaration merge for
NamedNodeMapI can't tell from the MDN docs for NamedNodeMap if it's standard or not. All they seem to mention is "Attr nodes' indexes may differ among browsers" which wouldn't apply to access by the attribute name.
Just wondering if this was omitted by mistake or is it because this is not considered WHATWG DOM standard? I went to dom.spec.whatwg.org/#interface-nam... and unless I'm reading it incorrectly, I believe it states that using a string indexer is valid.
Thoughts? Happy to PR this up if it's valid.
And finally, I've made a few PRs to dev.to to get back in the swing of things of contributing there as well.
What type of PR is this? (check all applicable)
Description
Fixed some linting issues being reported in the frontend.
Related Tickets & Documents
#1828
Mobile & Desktop Screenshots/Recordings (if there are UI changes)
Added to documentation?
[optional] What gif best describes this PR or how it makes you feel?
Boom!
Killing it!!
Between the scrubs gif and the TypeScript use, I feel like we’re BFFs now.
you man is woaaaaah!!!
