JSDocでよくね？

綾坂こと.icon

code:example.ts

function add(left: number, right: number): number {

return left + right;

}

code:example.js

/**

* 「型についての情報が書かれている部分」と「ロジックが書かれている部分」は分離されてたほうがわかりやすいと思う

* @param {number} left - 左項

* @param {number} right - 右項

* @returns {number} - 和

*/

function add(left, right) {

return left + right;

}

一番最初に見たものから離れられてないだけじゃないかな

考えたことなかったので面白い

どういうところがわかりやすくなったと感じているのか知りたい

ただ、タイトルの「JSDocでよくね？」はsyntaxの話と、型の有用性の話が混じっている気もする

やりたければ、TypeScriptでも型だけ定義して、あとから実装に紐づけることもできる

code:ts

type Add = (left: number, right: number) => number;

const add: Add = (left, right) => left + right;

こうすれば、コードの途中に型情報は書いていない(?)

(コードってどこ？というのはある)

関数名を型名にも使わなきゃいけないのがちょっと気になるが、これは私にとって読みやすい

あれは実装と型を完全に別ファイルに書いているので、コードの途中に型が書かれない

近く(できれば隣)に書いてあって欲しいけど、完全に一緒に書かれていてほしくない

果たしてあれが本当にわかりやすいと言えるだろうか

TypeScriptユーザがJSDocよりもTypeScriptを好むのは

そちらの方が記述量が少ない (syntax関連)

そちらの方が表現できる幅が広い (型の有用性)

とかそういうのが大きいと思う

syntaxの方は慣れとか好みの影響が大きい思う

TypeScriptをバリバリ好んで使う人にとっては、JSDocの表現力が自分の要求に全く届いていないから使っていないだけ

JSDocで十分ならそれで良い

TSユーザが小さいプログラムにも(JSDocではなく)TSを使うのは、

単にJSDocの記法を別途覚えるのが面倒、

プログラムが大きくなったときにTSに切り替えるのが面倒

とかそんな感じではないだろうか

その場合、コメントみたいに離れた世界にあるよりも、

同一のコードとして存在していたほうが処理系視点で扱いやすい

とかもありそう

JSにおいてもclass定義は型のようなもので、

ではこれを「コードから分離して書く」ならどうなるのか？というのは気になる

型定義が無いと、そもそもその関数が入力に何を求めていて何を出力するのかさっぱりわからないよね…？

部分的に変更できて何が良いかと言うと、型の柔軟性が高いからより厳密な型もより簡単に（回りくどいことをせずに）組めるということ

逆にJSDocを読み取るタイプの型チェッカーがどこまでできるのか知らないけれど、こういうことはできるのかな

code:possibleNull.ts

const foo = () => {

interface aryType {id: number, value?: unknown}

const possibleNull: aryType | undefined = ary.find(e => e.id === 1)

if (!possibleNull) return

// undefinedの可能性は消えたため、そのまま呼び出してもエラーにならない

console.log(possibleNull.id ** 10)

}

foo()

↓実行コマンド

型チェッカーの厳密度によると思うけれど、これができないなら厳密さの面でTypeScriptの方が勝るということになる

https://gyazo.com/f271de560904803aac565bfd7a764558

左の赤波線部分は「'possibleNull' は 'undefined' の可能性があります。」

code:possibleNull.js

// @ts-check

/**

* @typedef {Object} AryType

* @prop {number} id

* @prop {unknown} value

*/

const foo = () => {

/** @type {AryType[]} */

/** @type {AryType|undefined} */

const possibleNull = ary.find(a => a.id === 1);

if (!possibleNull) return;

console.log(possibleNull.id ** 10);

};

foo();

無視していいエッジケース

これは方法を知らないだけかもしれない

code:example.js

/** @type {{ name: string, age: number }} */

const userInfo = {

"name": "山田太郎",

"age": 18,

};

逆にこれらのトリッキーな型パズルさえ使わなければJSDocで十分

名前が定義されるタイミングでそれの型も定義されてて欲しくない？

code:example.js

/** @type {string} ユーザーの入力 */

const userInput = window.prompt();

拡張機能いくつか作ったから大分慣れたけどそれでも少し大きな拡張機能作るときは型宣言が無いと心配になる

まあ無い分の融通も受けてはいるんだけれども…

引数に何が入ってくるのか特定が非常に困難

今日deno+tsを使い始める => 井戸端にはts否定記事が書かれている

Pythonから入った身としてはコード内に型情報が入ることに特に違和感はない

(PythonではTSと同様の記法で型注釈をいれる)

表記的にすごく似ている

JavaScriptのダメなところを解消するためにはJSDocでは不十分だが、TypeScriptは十分であるとする理由

(素の)JavaScriptがダメなのはわかる

JSDocを認識させるissueは立っているが、活動していない

githubにあるコードの直リンクをimportできる

とはいえ、transpile不要という特徴が生かされる場面はあまり思いつかない

scrapbox内でコードを書く場合は重宝するかも

GitHub Pagesとかは自動でtranspileやってくれると認識しているので、それが強い理由かと言われると微妙

そのうちブラウザ内で直接TypeScriptが実行できるようになる気もする

(2024-09-19)ただ進展はそんなにない

難航してるっぽい

そうであれば難航するのも頷ける