免責事項
ねえ、始める前に、何かを明確にさせてください:私は自分のパッケージについて多くのことを話しますが、 ts-runtime-picker 、これはプロモーションの記事ではありません。私は自分の経験とそれを作る前に行った旅を共有しているだけです。 (しかし、ねえ、あなたが興味があるなら、ここにパッケージへのリンクがありますか?)。
少し巻き戻しましょう。それで、私はしばらくの間、TypeScriptを使用しています。私は自分をタイプスクリプトプロとは呼びませんが、いくつかの大きなプロジェクトを構築し、私の会社でそれと一緒に働いていました。通常の「Hello World」プロジェクト、少し複雑なプロジェクト、そしてもちろん、「このエラーはどういう意味ですか?」または「インターフェイスからフィールドを再度選択するにはどうすればよいですか?」 (あなたはポイントを得ます。??)
ある日、私はFirebaseクラウド関数を扱っている間に問題に遭遇しました。私は createUser endpointに参加し、検証ロジックを書き、データのトリミング、通常のCRUDリクエストの狂気を処理しました。前の開発者からこのコードに出くわすまで、すべてがスムーズに動いていました:
firebase.collection("users").add(request.data.user);
...そして、私の内なるタイプスクリプトプロは叫んでいました。 ?
つまり、はに来てください、これは巨大な赤い旗でした。右?そのように直接ろ過されていないユーザーデータを直接挿入することは危険でした。リクエストデータに検証が欠落していて、不要なフィールドをデータベースに挿入した場合はどうでしょうか。大きくはありません。
私はすぐにコードを削除しましたが、その後、私は一瞬凍結しました。 ? 「request.dataをユーザーインターフェイスタイプに割り当てるだけなら、タイプスクリプトがこのようなことをするのを止めないのではないでしょうか?」と考えて、画面を見つめました。 (私のIDEを希望に満ちた一目で、赤い波線が現れるのを待っています。)
しかし、待ってください…?♂ ♂■typeScriptはではありません魔法ではありません。コンパイル時間のチェックにすぎませんよね?ランタイムには存在しません。タイプスクリプトはタイプの安全性のためのマスクですが、コードが実行されているときに実際には何も強制しません。それはではありませんは実行時に余分なフィールドが挿入されないようにします。
だから、私はチームメイトの1人を呼び出して、「ちょっと仲間、アルファベットにすべての文字が付いたアルファベットという名前のオブジェクトがあるかどうか、「a」と「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);ビートを逃さずに、私のチームメイトは、「ハハ、まあ、タイプスクリプトはランタイムでそれを本当に止めることができないので、まだすべてのアルファベット文字を受け取るだろう」と言いました。
。
くそ。私はそれを知っていた。私は希望の効果がありました -タイプスクリプトが実行時に私が間違いを犯すことを魔法のように妨げることを望んでいます。 ? しかし、それは私にぶつかった:タイプスクリプトが実行時にこれを強制できるとしたらどうでしょう?特定のインターフェイスにオブジェクトをキャストし、型
がインターフェイスで定義されていないプロパティを自動的に削除できる場合はどうなりますか?が私の問題を解決するだろう。
ts-runtime-pickerの誕生
そしてそのように、 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.
前:手動検証
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.
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の力(そしてそれがイノベーションにつながる方法)
確かに、このアイデアの最初の火花は、私が少し怠zyであることから生まれました。データを挿入する必要があるたびにフィールドを手動でフィルタリングしたくありませんでした。しかし、ちょっと、時々怠inessは輝きにつながります! を簡単にするという欲求はイノベーションの原動力になります。
実際、最初の「怠iness」にもかかわらず、私は 8時間をパッケージの構築に費やしました。ええ、そうです。 ?
しかし、それが時々行く方法です。 「必要性は発明を生み出します」とこれは、退屈な繰り返しのチェックを避けるために、最終的に私の人生(そしてできれば他の多くの人生)をはるかに簡単にした新しい解決策につながりました。 だから、ボールを転がすことで怠lazを非難することができますが、
ts-runtime-pickerを生み出した問題を解決する必要がありました。そして、それが時々、
がスタックまたは怠zyであることは必ずしも悪いことではありません。それは新しくて便利な何かの発祥の地です!結論 そして、それが ts-runtime-picker
パッケージの背後にあるストーリーです。タイプスクリプトのフラストレーションから、本当の問題を解決するツールの作成への旅。このパッケージは、タイプスクリプトユーザーが開発中だけでなくランタイムでも最大限の安全性を活用するのを支援する私の方法です。免責事項: 提供されるすべてのリソースの一部はインターネットからのものです。お客様の著作権またはその他の権利および利益の侵害がある場合は、詳細な理由を説明し、著作権または権利および利益の証拠を提出して、電子メール [email protected] に送信してください。 できるだけ早く対応させていただきます。
Copyright© 2022 湘ICP备2022001581号-3