feat(misskey-js): エラーを型として出力・利用できるように

[kakkokari-gtyih]

What

• misskey-jsでのエラーハンドリングでエラー型を使えるように
  • generatorにそれ用のコードを追加
• os.apiWithDialogで、エラーコードごとにカスタムエラーメッセージを指定できるように
• misskeyApiのreject側の戻り値にエラー型が出るように

Why

• エラーの型が使えると便利
• apiWithDialogに特別な変更を加えなくても独自のエラーダイアログを追加できて楽

Additional info (optional)

独自エラーの追加はこんな感じ

os.apiWithDialog(pin ? 'i/pin' : 'i/unpin', {
	noteId: appearNote.id,
}, token, {
	PIN_LIMIT_EXCEEDED: { // ←ここにも型が効く
		// titleも指定可能（任意）
		text: i18n.ts.pinLimitExceeded,
	},
});

Checklist

• Read the contribution guide
• Test working in a local environment
• (If needed) Add story of storybook
• (If needed) Update CHANGELOG.md
• (If possible) Add tests

[codecov]

Codecov Report

Attention: Patch coverage is 6.18557% with 91 lines in your changes missing coverage. Please review.

Project coverage is 65.25%. Comparing base (b269c43) to head (3156b2d).

Files	Patch %	Lines
packages/frontend/src/os.ts	6.97%	80 Missing ⚠️
packages/frontend/src/scripts/misskey-api.ts	0.00%	11 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           develop   #14069       +/-   ##
============================================
- Coverage    77.90%   65.25%   -12.66%     
============================================
  Files          185     1004      +819     
  Lines        25563   115306    +89743     
  Branches       487     5541     +5054     
============================================
+ Hits         19916    75246    +55330     
- Misses        5640    38621    +32981     
- Partials         7     1439     +1432     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[kakkokari-gtyih]

paramsを入力するまでは型が認識されてるのに、paramsを入力しようとすると型が消える

謎

[anatawa12]

misskey/packages/misskey-js/src/api.ts

Lines 52 to 56 in 2acbec6

	public request<E extends keyof Endpoints, P extends Endpoints[E]['req']>(
	endpoint: E,
	params: P = {} as P,
	credential?: string | null,
	): Promise<SwitchCaseResponseType<E, P>> {

Pがジェネリクスなのでそうなる

[kakkokari-gtyih]

どう直せば型補完がちゃんと効くようになるかしら・・・

[anatawa12]

Ideaであれば補完自体は出てきたと思うけどVSCだとだめなのか

[kakkokari-gtyih]

code側の問題？

[kakkokari-gtyih]

codeのアプデ来てたのでちょっと試してみます

[anatawa12]

IDEAだとでたね。Code側の問題か、codeのしようかですね(IDEAがjsのlanguage serverを生で使ってる保証はない)

[kakkokari-gtyih]

codeのアプデ来てたのでちょっと試してみます

だめだった

[kakkokari-gtyih]

モノ自体はなにもおかしくないしエラーハンドリングはちゃんと型定義通っているのでマージしても大丈夫そう
環境によっては型補完がでるっぽいので

[anatawa12]

ErrPromise<T,RE>という方針、fetchの各種エラー(fetch がネットワークエラーを発生した場合のTypeErrorとか)がMisskey.Endpoints[E]['errors']に化けちゃってすごく良くない気がします。

[kakkokari-gtyih]

ErrPromise<T,RE>という方針、fetchの各種エラー(fetch がネットワークエラーを発生した場合のTypeErrorとか)がMisskey.Endpoints[E]['errors']に化けちゃってすごく良くない気がします。

そのとおりだけど良い直し方が思いつかない…

[KisaragiEffective]

nominal type idiomで各エラーを包んだらいい感じにそのふるまいをオプトアウト出来そう

[anatawa12]

私はそもそも元の実装からそうですがJsonのオブジェクトをそのままthrow(reject)するのが悪手だと思ってます。

ApiError的なErrorを継承したclassのインスタンスにしてthrowするようにし、これのエラーペイロードに関してMisskey.Endpoints[E]['errors']であるとするのは(未だにas必要にはなるけど)やって良い範囲の仮定だと思ってます

[kakkokari-gtyih]

大規模にコードを修正しないといけない割には使用箇所が限られるので今やる必要はないかも

[KisaragiEffective]

私はそもそも元の実装からそうですがJsonのオブジェクトをそのままthrow(reject)するのが悪手だと思ってます。

ApiError的なErrorを継承したclassのインスタンスにしてthrowするようにし、これのエラーペイロードに関してMisskey.Endpoints[E]['errors']であるとするのは(未だにas必要にはなるけど)やって良い範囲の仮定だと思ってます

これについてはCONTRIBUTING.mdで禁止したあとno-throw-literalをerrorにして違反箇所を随時潰していくしかないと思っている

[anatawa12]

instanceofは公称型のチェックになるのでreason instanceof APIErrorにしてMK_API_ERROR symbolはなくしていい気がする。