免責聲明
嘿，在我們開始之前，讓我澄清一下：雖然我會談論很多關於我的包的內容，ts-runtime-picker，但這不是一篇促銷文章。我只是分享我的經驗和建造它之前的旅程。 （但是嘿，如果您好奇，這是該包的連結？）。
讓我們回顧一下。所以，我已經使用 TypeScript 有一段時間了。我不會稱自己為 TypeScript 專業人士，但我已經建立了一些大型專案並在我的公司使用它。你知道，常見的一些“hello world”項目，一些稍微複雜的項目，當然，還有相當一部分去谷歌找出“這個錯誤到底意味著什麼？”或“如何再次從界面中選擇字段？” （你明白了。
有一天，我在使用 Firebase 雲端函數時遇到了問題。我在createUser 端點上編寫我的驗證邏輯、修剪資料並處理常見的 CRUD 請求。一切都進展順利，直到我遇到了以前的開發人員的這段程式碼：
firebase.collection("users").add(request.data.user);
我的意思是，
來吧，這是一個巨大的危險信號。正確的？像這樣直接插入未經過濾的用戶資料是有風險的——如果請求資料缺少一些驗證並且我們最終將不需要的欄位插入資料庫中怎麼辦？不太好。
我很快就刪除了程式碼，但隨後我愣了一下。 ？我盯著螢幕思考：「等等，如果我只是將request.data 分配給使用者介面類型，TypeScript 不會阻止我做這樣的事情嗎？這不是應該解決問題嗎？」（充滿希望地看了一眼我的IDE，等待紅色波浪線出現。但是等等…？ ♂️ TypeScript
不是魔法。這只是編譯時檢查，對吧？它在運行時不存在。 TypeScript 是類型安全的掩碼，但在程式碼運行時它實際上並不會強制執行任何操作。它並沒有真正阻止在運行時插入額外的字段。 所以，我打電話給我的一位隊友並問道：「嘿兄弟，如果我們有一個名為Alphabet 的對象，其中包含字母表中的所有字母，並且我們創建一個接口OnlyTwoLetters，只允許字母'a' 和' b'，當我們將字母表物件投射到該介面時會發生什麼？
我的隊友毫不猶豫地說：「哈哈，好吧，你仍然會得到所有字母，因為 TypeScript 無法在運行時真正阻止它。」
該死。我就知道。我滿懷希望——希望 TypeScript 能夠神奇地防止我在運行時犯錯。 ？
但是隨後，我突然想到：如果 TypeScript 可以在運行時強制執行此操作會怎麼樣？如果我們可以將一個物件轉換為特定的接口，並讓 TypeScript 自動去除接口中未定義的任何屬性，會怎麼樣？
那可以解決我的問題。
所以，在這個靈光乍現的時刻，我想：「為什麼不讓這成為現實呢？」如果我可以將request.data 轉換為使用者介面，TypeScript 可以幫助我自動刪除任何額外的屬性，使物件可以安全地插入Firebase 中。 ？
就這樣，ts-runtime-picker 的想法誕生了。目標很簡單：建立一個包，允許 TypeScript 使用者根據特定介面中定義的欄位從物件中過濾掉不需要的屬性。
最好的部分？它將使我免於手動驗證和過濾欄位。那些日子已經一去不復返了：
firebase.collection("users").add(request.data.user);
使用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);
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。這樣就少了一件需要擔心的事情，而且它讓使用 TypeScript 變得更聰明。 ？
以上是超越類型安全：透過建置執行時間選擇器使 TypeScript 更智能的詳細內容。更多資訊請關注PHP中文網其他相關文章！
