I wonder how useful and how annoying it will turn out to be. In any case, deleting them would be a few clicks in the editor. But it looks not terrible and it should at least make refactoring safer 🤔
If you use a parameter object in JavaScript, even if you specify its shape using JSDoc, you’ll only get errors if required properties are missing; not if there are extra properties provided.
e.g.,
class A {
/**
@param {{
id:string
}} params
*/
constructor (params) {
Object.assign(this, params)
}
}
// Error:
new A({})
// No error:
new A({id: 'x', foo:'bar'})
#TIL#TypeScript can type-check #JavaScript files (to extent it's possible) with allowJs and checkJs compiler options. Moreover, it even takes hints from #JSDoc. This makes gradual migration to TS even more compelling as we get type feedback even for existing JS files
I don't like how this is documented. It's on a page about DOM manipulation with TypeScript, which makes some sense, but I didn't see anything about doing this in JS with JSDoc. It says it's defined in lib.dom.d.ts and I thought I might have to import a type definition somehow.
You can argue for learning the fundamentals and using "Vanilla" #JavaScript all day long... I'll probably join you... but using #TypeScript and #JSDoc types in JS is forcing me to learn the HTML DOM and Web APIs better.
I am trying to use #TypeScript on normal #JavaScript files using #JSDoc, and I have to say I like it so far. It shows me errors and provides good auto completion and all of that without a build step. Just wrote a few lines yet, therefore I have to ask: Does anyone know any downsides of this approach? 🤔
Yeah, I have no idea how this is still an issue in JSDoc in 2023. It looks like the project is abandoned – which is a damn shame for those of us who want type safety without having to introduce a build step using TypeScript in our projects.
If your #js function takes a parameter object and uses spread syntax to collect arbitrary additional properties (rest) and you want to document it using #JSDoc, the syntax is:
If you need to use a type definition in an external file multiple times, you don’t have to keep writing import(…).type over and over. Just create a new type definition in your local file and use that.
e.g.,
/** @typedef {import('./SetupState.js').SetupStateType} SetupStateType */
const state = {
domain: /** @type SetupStateType */ (new SetupState('Domain')),
server: /** @type SetupStateType */ (new SetupState('Server')),
…
}
TypeScript! What is it good for? I wouldn’t go as far as to say “absolutely nothing” like the song. I’m not trying to start a war here. It certainly is widespread, with JetBrains estimating it has nearly tripled in popularity over the past six years. However, we are scientists and using popularity as a reason for adopting a new tool is an excellent way to commit a logical fallacy.
Since generics were not working very well in #JSDoc 6 months ago, I still have this lingering feeling that tossing #TypeScript right away in favor of JSDoc is going to hurt some projects. If the situation with "templates"/generics has been resolved since then, then I would be able to seriously suggest moving to such opt-in commenting.
I love it when a library lets you choose between #JavaScript and #Typescript in the code examples, but I wish that they would include the #JSDoc types in the #JS version since they don't hurt anything and they are still helpful when you're using #VSCode#WebDev
It's an interesting route, and I didn't see much projects that would move away from #TypeScript to #JSDoc type hints. I tried writing generics in it some months ago and didn't find this experience pleasing at all. But I hope this doesn't serve as a limitation for making #Svelte type-safe.