ホームページ >ウェブフロントエンド >jsチュートリアル >タイプ セーフティを超えて: ランタイム ピッカーを構築して TypeScript をよりスマートにする

タイプ セーフティを超えて: ランタイム ピッカーを構築して TypeScript をよりスマートにする

Susan Sarandon
Susan Sarandonオリジナル
2024-12-16 20:25:15738ブラウズ

Beyond Type Safety: making TypeScript smarter by Building a Runtime Picker

免責事項

ねえ、始める前に、はっきりさせておきたいことがあります。私のパッケージ ts-runtime-picker についてたくさん話しますが、これは宣伝記事ではありません。私は私の経験と、それを構築するまでに行った旅を共有しているだけです。 (でもまあ、興味があるなら、ここにパッケージへのリンクがあります?).


TypeScript が私を新しいアイデア (そしてパッケージ) に導いた方法

少し巻き戻してみましょう。そこで、私はしばらく TypeScript を使って作業してきました。私は自分自身を TypeScript プロとは呼びませんが、いくつかの大きなプロジェクトを構築し、会社でそれに取り組んできました。ご存知のとおり、通常は、いくつかの「Hello World」プロジェクト、いくつかの少し複雑なプロジェクト、そしてもちろん、「このエラーは一体何を意味するのか?」を理解するために Google にアクセスすることもかなりありました。または「インターフェイスからフィールドを再度選択するにはどうすればよいですか?」 (意味が分かりましたね?)

ある日、Firebase クラウド機能を使用しているときに問題に遭遇しました。私は createUser エンドポイント上で検証ロジックを作成し、データをトリミングし、通常の CRUD リクエストの処理を行っていました。以前の開発者が作成した次のコードに遭遇するまでは、すべてがスムーズに進んでいたのです。

firebase.collection("users").add(request.data.user);

...そして私の中の TypeScript プロが悲鳴を上げていました。 ?

つまり、さあ、、これは重大な危険信号です。右?このようにフィルターされていないユーザー データを直接挿入するのは危険でした。リクエスト データに検証が欠けていて、不要なフィールドをデータベースに挿入してしまったらどうなるでしょうか?あまり良くありません。

すぐにコードを削除しましたが、その後、一瞬フリーズしてしまいました。 ?私は画面を見つめながらこう考えました。「ちょっと待って、request.data をユーザー インターフェイスの型に割り当てるだけなら、TypeScript がこのようなことを止めてくれるんじゃないでしょうか? これで問題は解決するはずではないでしょうか?」 (赤い波線が表示されるのを待ちながら、IDE を希望に満ちた視線で見つめます。)

でもちょっと待ってください… ?‍♂️ TypeScript は魔法ではありません。単なるコンパイル時のチェックですよね?実行時には存在しません。 TypeScript はタイプ セーフティのマスクですが、コードの実行中に実際には何も強制しません。実行時に追加のフィールドが挿入されるのを本当に止めるわけではありません。

そこで、私はチームメイトの 1 人に電話して尋ねました。「おい、アルファベットのすべての文字を含む alphabets という名前のオブジェクトがあり、文字 'a' と ' のみを許可するインターフェイス OnlyTwoLetters を作成するとする」 「b'、アルファベット オブジェクトをそのインターフェイスにキャストすると何が起こるでしょうか?」

// Object with all alphabet letters
const alphabets = {
  a: 'Apple',
  b: 'Banana',
  c: 'Cherry',
  d: 'Date',
  e: 'Eggplant',
  f: 'Fig',
  // ... all the way to z
};

// Interface that only allows 'a' and 'b'
interface OnlyTwoLetters {
  a: string;
  b: string;
}

// Casting alphabets to OnlyTwoLetters
const filteredAlphabets = alphabets as OnlyTwoLetters;

console.log(filteredAlphabets);

私のチームメイトは間髪入れずにこう言いました。「ははは、そうですね、それでもすべてのアルファベット文字を取得できるでしょう。TypeScript は実行時にそれを実際に止めることはできないからです。」

くそー。私はそれを知っていた。私は TypeScript が実行時のミスを魔法のように防いでくれるという期待に憧れていました。 ?

しかし、次に、TypeScript が実行時にこれを強制できたらどうなるだろうかと思いつきました。オブジェクトを特定のインターフェイスにキャストし、インターフェイスで定義されていないプロパティを TypeScript で自動的に削除できるとしたらどうなるでしょうか?

それは私の問題を解決するでしょう。


ts-runtime-picker の誕生

そこで、この電球の瞬間に、「これを現実にしてみませんか?」と考えました。 request.data をユーザー インターフェースにキャストできれば、TypeScript を使用して余分なプロパティを 自動的に 削除して、オブジェクトを Firebase に安全に挿入できるようになります。 ?

そしてまさにそのようにして、ts-runtime-picker のアイデアが生まれました。目標は単純でした。TypeScript ユーザーが、特定のインターフェイスで定義されたフィールドに基づいて、オブジェクトから不要なプロパティをフィルターで除外できるパッケージを作成することでした。

一番良かった点は?そうすれば、手動でフィールドを検証したりフィルタリングしたりする必要がなくなります。
の時代は終わりました。

firebase.collection("users").add(request.data.user);

仕組み: TypeScript に仕事をさせましょう

ts-runtime-picker を使用すると、プロセス全体が自動化されます。オブジェクトをインターフェイスにキャストすると、パッケージによってインターフェイスで定義されたプロパティのみが保持されることが保証されます。実際の動作は次のとおりです:

前: 手動検証

// Object with all alphabet letters
const alphabets = {
  a: 'Apple',
  b: 'Banana',
  c: 'Cherry',
  d: 'Date',
  e: 'Eggplant',
  f: 'Fig',
  // ... all the way to z
};

// Interface that only allows 'a' and 'b'
interface OnlyTwoLetters {
  a: string;
  b: string;
}

// Casting alphabets to OnlyTwoLetters
const filteredAlphabets = alphabets as OnlyTwoLetters;

console.log(filteredAlphabets);

後: ts-runtime-picker を使用

const filteredData = {
  name: requestData.name,
  age: requestData.age,
};

firebase.collection("users").add(filteredData);  // More work, less fun.

一番良かった点は?このコードはデフォルトでは安全です。手動によるチェックやオブジェクトの操作は必要ありません。 ts-runtime-picker は、ユーザー インターフェイスに存在しないフィールドをすべてフィルターして除外することで、これを自動的に処理します。誤ってフィールドを挿入することを心配することなく、コアロジックだけに集中できます。 ?


怠惰の力 (そしてそれがどのようにイノベーションにつながるのか)

それで、あなたはこう疑問に思うかもしれません。「これはまったくの怠惰から来たのでしょうか?」それに対して私はこう言います: はい、でもいいえです。 ?

確かに、このアイデアの最初のきっかけは、私が少し怠け者だったことから生まれました。データを挿入する必要があるたびにフィールドを手動でフィルターしたくなかったのです。でもね、怠惰が輝きにつながることもあるのよ! 物事を簡単にしたいという願望は、イノベーションの原動力となりえます。

実際、最初は「怠惰」だったにもかかわらず、私はパッケージの構築に 8 時間 を費やしました。はい、その通りです。 ?

しかし、時にはそういうこともあるのです。 「必要性が発明を生む」。この面倒な繰り返しのチェックを避ける必要性が、最終的に私の生活 (そして願わくば他の多くの人々の生活) をずっと楽にする新しいソリューションを生み出しました。

したがって、問題を解決するのに怠惰を責めることもできますが、ts-runtime-pickerを引き起こした問題を解決する必要があったのです。このように、行き詰まったり、怠けたりすることは、必ずしも悪いことではありません。それは、新しくて便利なものが生まれる場所なのです。


結論

これが ts-runtime-picker パッケージの背後にある物語です。 TypeScript の不満から、実際の問題を解決するツールを作成するまでの道のり。このパッケージは、TypeScript ユーザーが開発時だけでなく実行時においてもタイプ セーフティを最大限に活用できるようにするための私なりの方法です。

手動でフィールドをフィルタリングするのにうんざりしている場合、または不要なデータが忍び込むのが心配な場合は、ts-runtime-picker を試してみてください。心配することが 1 つ減り、TypeScript の操作が少しだけスマートになります。 ?

以上がタイプ セーフティを超えて: ランタイム ピッカーを構築して TypeScript をよりスマートにするの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明:
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。