「労働者が自分の仕事をうまくやりたいなら、まず自分の道具を研ぎ澄まさなければなりません。」 - 孔子、「論語。陸霊公」
表紙 > プログラミング > タイプの安全性を超えて:TypeScriptランタイムセレクター内詳細分析

タイプの安全性を超えて:TypeScriptランタイムセレクター内詳細分析

2025-03-12に投稿されました
ブラウズ:652

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

免責事項

ねえ、始める前に、何かを明確にさせてください:私は自分のパッケージについて多くのことを話しますが、 ts-runtime-picker 、これはプロモーションの記事ではありません。私は自分の経験とそれを作る前に行った旅を共有しているだけです。 (しかし、ねえ、あなたが興味があるなら、ここにパッケージへのリンクがありますか?)。


タイプスクリプトがどのように私を新しいアイデア(およびパッケージ)に導いたか

少し巻き戻しましょう。それで、私はしばらくの間、TypeScriptを使用しています。私は自分をタイプスクリプトプロとは呼びませんが、いくつかの大きなプロジェクトを構築し、私の会社でそれと一緒に働いていました。通常の「Hello World」プロジェクト、少し複雑なプロジェクト、そしてもちろん、「このエラーはどういう意味ですか?」または「インターフェイスからフィールドを再度選択するにはどうすればよいですか?」 (あなたはポイントを得ます。??)

ある日、私はFirebaseクラウド関数を扱っている間に問題に遭遇しました。私は createUser endpointに参加し、検証ロジックを書き、データのトリミング、通常のCRUDリクエストの狂気を処理しました。前の開発者からこのコードに出くわすまで、すべてがスムーズに動いていました:

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

...そして、私の内なるタイプスクリプトプロは叫んでいました。 ?

つまり、に来てください、これは巨大な赤い旗でした。右?そのように直接ろ過されていないユーザーデータを直接挿入することは危険でした。リクエストデータに検証が欠落していて、不要なフィールドをデータベースに挿入した場合はどうでしょうか。大きくはありません。

私はすぐにコードを削除しましたが、その後、私は一瞬凍結しました。 ? 「request.dataをユーザーインターフェイスタイプに割り当てるだけなら、タイプスクリプトがこのようなことをするのを止めないのではないでしょうか?」と考えて、画面を見つめました。 (私のIDEを希望に満ちた一目で、赤い波線が現れるのを待っています。)

しかし、待ってください…?‍♂ ‍♂■typeScriptはではありません魔法ではありません。コンパイル時間のチェックにすぎませんよね?ランタイムには存在しません。タイプスクリプトはタイプの安全性のためのマスクですが、コードが実行されているときに実際には何も強制しません。それはではありませんは実行時に余分なフィールドが挿入されないようにします。

だから、私はチームメイトの1人を呼び出して、「ちょっと仲間、アルファベットにすべての文字が付いたアルファベットという名前のオブジェクトがあるかどうか、「a」と「b」のみを許可するインターフェイスのみを作成します。

//すべてのアルファベット文字を含むオブジェクト const alphabets = { A:「Apple」、 B:「バナナ」、 C:「チェリー」、 D:「日付」、 E:「ナス」、 F:「イチジク」、 // ... zまでずっと }; //「a」と「b」のみを許可するインターフェイス インターフェースのみの唯一の{ A:文字列; B:文字列; } // Alphabetsを唯一のtowolettersに鋳造します const filteredalphabets = alphabets as Onlytwoletters; console.log(filteredalphabets);
// 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の誕生

だから、この光の瞬間があるので、私は次のように思いました。「これを現実にしてみませんか?」 request.dataをユーザーインターフェイスにキャストできた場合、typeScriptはを自動的に

追加のプロパティを削除し、オブジェクトをFirebaseに安全に挿入するのに役立ちます。 ?

そしてそのように、 ts-runtime-picker

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

最良の部分?それは、フィールドの手動検証とフィルタリングから私を救うでしょう。 の時代はなくなりました

const filtereddata = { 名前:requestdata.name、 年齢:requestdata.age、 }; firebase.collection( "users")。add(filtereddata); //より多くの仕事、それほど楽しくない。


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

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

ts-runtime-picker を使用して、プロセス全体が自動化されます。インターフェイスにオブジェクトをキャストでき、パッケージはインターフェイスで定義されているプロパティのみが保持されることを確認します。これが動作の仕組みです:

前:手動検証

インターフェイスユーザー{ 名前:文字列; 年齢:数; } const requestdata = {name: 'john'、age:30、address: '123 Street'}; //不要なフィールドを手動で確認して削除します。 const filteredData = { 名前:requestdata.name、 年齢:requestdata.age、 }; firebase.collection( 'users')。add(filtereddata); //あまりエレガントではありません。

後:ts-runtime-picker
interface User {
  name: string;
  age: number;
}

const requestData = { name: 'John', age: 30, address: '123 Street' };

// Manually check and remove unwanted fields:
const filteredData = {
  name: requestData.name,
  age: requestData.age,
};

firebase.collection('users').add(filteredData);  // Not very elegant.

'ts-runtime-picker'から{pick}をimport; インターフェイスユーザー{ 名前:文字列; 年齢:数; } const requestdata = {name: 'john'、age:30、address: '123 Street'}; //存在しないプロパティを自動的に除去します。 const safedata = pick(requestdata、user); firebase.collection( 'users')。add(safedata); //はるかクリーナー! 最良の部分?このコードは、デフォルトでは

Safe
import { pick } from 'ts-runtime-picker';

interface User {
  name: string;
  age: number;
}

const requestData = { name: 'John', age: 30, address: '123 Street' };

// Automatically filters out non-existent properties:
const safeData = pick(requestData, User);

firebase.collection('users').add(safeData);  // Much cleaner!

怠lazの力(そしてそれがイノベーションにつながる方法)


だから、あなたは疑問に思うかもしれません:「これは純粋な怠inessから出てきましたか?」そしてそれに、私は言います:はい、しかし、いいえ。

確かに、このアイデアの最初の火花は、私が少し怠zyであることから生まれました。データを挿入する必要があるたびにフィールドを手動でフィルタリングしたくありませんでした。しかし、ちょっと、時々怠inessは輝きにつながります! を簡単にするという欲求はイノベーションの原動力になります。

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

しかし、それが時々行く方法です。 「必要性は発明を生み出します」とこれは、退屈な繰り返しのチェックを避けるために、最終的に私の人生(そしてできれば他の多くの人生)をはるかに簡単にした新しい解決策につながりました。 だから、ボールを転がすことで怠lazを非難することができますが、

ts-runtime-picker

を生み出した問題を解決する必要がありました。そして、それが時々、

がスタックまたは怠zyであることは必ずしも悪いことではありません。それは新しくて便利な何かの発祥の地です!

結論 そして、それが ts-runtime-picker

パッケージの背後にあるストーリーです。タイプスクリプトのフラストレーションから、本当の問題を解決するツールの作成への旅。このパッケージは、タイプスクリプトユーザーが開発中だけでなくランタイムでも最大限の安全性を活用するのを支援する私の方法です。
フィールドのフィルタリングにうんざりしている場合、または不要なデータが忍び込んでいることを心配している場合は、

ts-runtime-picker を試してください。心配することは1つではなく、TypeScriptを使用して少し賢くなります。 ?

リリースステートメント この記事は、https://dev.to/hichemtab-tech/beyond-type-safety-typescript-smarter-by-building-a-runtime-picker-26d5に再現されています。
最新のチュートリアル もっと>

免責事項: 提供されるすべてのリソースの一部はインターネットからのものです。お客様の著作権またはその他の権利および利益の侵害がある場合は、詳細な理由を説明し、著作権または権利および利益の証拠を提出して、電子メール [email protected] に送信してください。 できるだけ早く対応させていただきます。

Copyright© 2022 湘ICP备2022001581号-3