TypeScriptにResult型を導入するための妥協点はどこか？
現実のアプリケーションで発生するすべてのエラー・例外をResult型に変換するのは非現実的 エラーハンドリングが不要なものはUnexpectedErrorとしてまとめてしまう という現実的な落とし所を提案する記事です。 TypeScriptにResult型を導入したくなる理由 TypeScriptのエラーハンドリングは、try…catch文を使うのが基本です。tryブロック内でthrowされた例外はcatchブロックで捕捉されます。 try…catchによるエラーハンドリングには、以下の問題があります。 例外がthrowされる可能性がある関数かどうかが型シグネチャに表れないため、呼び出し時にtry…catchが必要かどうかわからない exceptionVarの型がunknown（設定によってはany）のため、エラーの種類に応じたハンドリングができない try…catchを細かく切って個別に
Reactのデータ再取得、タイムスタンプで管理すると宣言的になる話【AI生成】
この記事は、AIが生成した記事を無修正で公開しています。投稿者（人間）の普段の作風・意見と異なる点や内容の粗もありますが、技術記事として公開するに足るクオリティであるという投稿者の判断と責任により投稿するものです。 ただし、記事に含まれる、経験に基づくエピソードは全てAIによる創造である点はご了承ください。 ちなみに、記事の生成は事前に用意したスタイルガイドに基づき、人間が記事のアイデアと結論を与えてAI (Claude Code) が出力したものであり、出力結果に対する追加の修正依頼などは行わない一発撮りです。 皆さんこんにちは。最近、データ再取得の実装パターンについて考えていて、面白い気づきがあったので共有します。 Reactでデータを再取得したいとき、普通はrefetch()みたいな関数を呼ぶ実装になります。ボタンを押したらサーバーからデータを取り直す、みたいなやつです。でも、これっ
適切なタイミングで情報をキャッチできていない時の対処法 - Konifar's ZATSU
マネージャーや横断チームのリードを担っていると、自然と他チームとの関わりが増える。 他チームと関わる中では、必要な情報を適切に把握しておくことが大事。それができていないと、よい意思決定ができなかったり常に周囲に振り回されてしまったりして成果を出しづらい。たとえば、「品質保証に責務を持つ横断チームなのにいつのまにか知らない機能のリリースが進んでいた」みたいなやつである。 こういう「適切なタイミングで情報をキャッチできていない」という状況はわりと発生しやすい。そういう時に情報をキャッチできるように対処するプロセスを雑に書き出してみる。 1. 役割を明確にする 何に責務を持っていて何をする人/チームなのかを明確にすること 役割を知ってもらう前にまず自分自身やチームの中で認識を揃えることが大事 意外と役割自体がふわっとしていることも多く、その状態だと当然必要な情報も集まってこない 2. 役割の認識
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
