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.
That's awesome!!! May be you can share a few tips about how to do what you have done successfully? E.g. how did you discover the problem and what did you do to isolate, solve and deliver the solution? What did you learn on the way?
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.
I would say only work on stuff that you find interesting and challenging. Otherwise don't bother. You won't enjoy it.
When I first started learning react, I started contributing as a way of learning. I found a react boilerplate project, react-slingshot, and just started offering suggestions that became PRs, and also did bug fixes. Eventually I was asked to become a maintainer to which I said yes.
Takeaway from this is open source is a great way to learn from others and if you contribute enough to a project, you may be asked to become a maintainer (if that's your jam).
In terms of problems/solutions, the more recent one I had while converting the Refined GitHub extension to TypeScript (TS), I had converted everything to TS, but webpack builds were failing. So initially, I tried some configuration changes in regards to webpack and the TS config, but no dice. I compiled each entry point from webpack directly with the TS compiler and they built fine, so clearly something was not right with webpack/TS situation.
Nick Taylor
@nickytonline
Trying to wrap up a PR. Current status... debugging webpack/ts-loader issues #typescript
01:51 AM - 17 Apr 2019
03
At this point I started to debug webpack, specifically the ts-loader plugin. If you've never debugged webpack code, you can run the following command to get started with the debugger. node --inspect-brk ./node_modules/webpack/bin/webpack.js. I found the error that was being thrown from webpack in the code and put a breakpoint there. First I saw that the files weren't being generated. When I reran the debugger, this time I saw that a particular boolean was not set properly which was related to webpack/TS configuration. Once I fixed the configuration, I was good to go. Takeaways, use your tools. Also, I was probably tired at this point and probably missed the obvious misconfiguration. 🙃
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.
I've really been enjoying contributing to open source and I definitely agree with you that even documentation is valuable to OSS.
Any contribution to Open Source is valuable
Nick Taylor
I'm still feeling really good about my past week, so I'm just gonna drop this here as it relates to the post.
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!
That's awesome!!! May be you can share a few tips about how to do what you have done successfully? E.g. how did you discover the problem and what did you do to isolate, solve and deliver the solution? What did you learn on the way?
I would say only work on stuff that you find interesting and challenging. Otherwise don't bother. You won't enjoy it.
When I first started learning react, I started contributing as a way of learning. I found a react boilerplate project, react-slingshot, and just started offering suggestions that became PRs, and also did bug fixes. Eventually I was asked to become a maintainer to which I said yes.
React + Redux starter kit / boilerplate with Babel, hot reloading, testing, linting and a working example app built in
A comprehensive starter kit for rapid application development using React.
Why Slingshot?
npm startto start development in your default browser.npm run buildto do all this:Get Started
Initial Machine Setup
First time running the starter kit? Then complete the Initial Machine Setup.
Clone the project
git clone https://github.com/coryhouse/react-slingshot.git.Run the setup script
npm run setupRun the example app
npm start -sThis will run the automated build process, start…
Takeaway from this is open source is a great way to learn from others and if you contribute enough to a project, you may be asked to become a maintainer (if that's your jam).
At this point I started to debug webpack, specifically the ts-loader plugin. If you've never debugged webpack code, you can run the following command to get started with the debugger.
node --inspect-brk ./node_modules/webpack/bin/webpack.js. I found the error that was being thrown from webpack in the code and put a breakpoint there. First I saw that the files weren't being generated. When I reran the debugger, this time I saw that a particular boolean was not set properly which was related to webpack/TS configuration. Once I fixed the configuration, I was good to go. Takeaways, use your tools. Also, I was probably tired at this point and probably missed the obvious misconfiguration. 🙃Awesome!
Sure, no problem.
👍🏻 thanks a lot!