听着,我们需要谈谈你的类型检查瘾。是的,您——在您的身份验证中间件中进行了 47 个instanceof 检查。编写的测试用例多于实际代码的开发人员。将 TypeScript 视为只是花哨的 JSDoc 注释的人。
让我给你画一幅图画:现在是中午,你正在喝第四杯咖啡,并且正在调试一个生产问题。日志显示用户以某种方式通过了十五层运行时验证。你的单元测试比 Twitter 的活跃用户还要多,但不知何故,不知何故,有人设法在应该是字符串的地方发送了一个数字。
“但那是不可能的!”你哭了,滚动浏览测试覆盖率报告,显示原始的 100%。 “我检查过这个!”
你有吗?你真的吗?或者您是否只是将同一张支票写了三遍:
这是一个革命性的想法:如果我们......信任编译器会怎样?我知道,疯狂的概念。但请听我说完。
interface ValidRabbit { username: string; password: string; } interface InvalidRabbit { username: number; password: string; } type ValidateRabbit<Rabbit> = Assert< //assert that Rabbit is of type {username, password} Is.Type< User, { username: string; password: string; } >, //custom compile time exceptions "Trix are for kids. Provide a username and password.", User >; // Ha! Silly Rabbit... function checkRabbit<T>(rabbit: ValidateRabbit<T>) { // .... protect your trix } declare const rabbit1: ValidRabbit; declare const rabbit2: InvalidRabbit; checkRabbit(rabbit1); checkRabbit(rabbit2); /** ~~~~~~~~~ * └───── Type Exception! "...Provide a username and password" */
我现在可以听到您的声音:“但是如果有人向我的 API 发送无效的 JSON 怎么办?”
首先,谁伤害了你?其次,是的,验证您的 API 边界。但是,一旦该数据进入您的打字稿域,就该放手了。让编译器成为你的保镖。
以下是拜占庭为您的信任问题聚会带来的内容:
// Define your trust boundaries type APIRequest<Request> = Assert< And< Is.On<Request, "body">, Or<Is.In<Request["method"], "POST">, Is.In<Request["method"], "PUT">> >;, "Someone's being naughty with our API" >; // Now everything inside is type-safe function handleRequest<R>(req: APIRequest<R>) { // If it compiles, it's valid // If it's valid, it compiles // This is the way }
想象一下:您的 CI/CD 管道在几分钟内完成,而不是几小时。您的生产日志中不会充满类型错误。您的 AWS 账单看起来不像电话号码。
怎么样?因为拜占庭将类型检查移至编译时。没有了:
// Before: Your CPU crying for help function validateUserMiddleware(req, res, next) { try { validateId(req.params.id) // CPU cycle validateBody(req.body) // CPU cycle validatePermissions(req.user) // CPU cycle validateToken(req.headers.auth) // CPU cycle // Your CPU is now considering a career change next() } catch (e) { res.status(400).json({ error: e.message }) } } // After: Your CPU sending you a thank you note type ValidRequest = Assert< And< Is.On<Request, 'params.id'>, Is.On<Request, 'body'>, Is.On<Request, 'user'>, Is.On<Request, 'headers.auth'> >, "Invalid request shape" >; function handleRequest(req: ValidRequest) { // Just business logic, no trust issues }
伟大的!为真正需要测试的东西编写测试:
你知道什么不需要测试吗?字符串是否实际上是字符串。让 TypeScript 来处理这场生存危机。
更快的发展
更好的性能
提高安全性
DevOps 梦想
interface ValidRabbit { username: string; password: string; } interface InvalidRabbit { username: number; password: string; } type ValidateRabbit<Rabbit> = Assert< //assert that Rabbit is of type {username, password} Is.Type< User, { username: string; password: string; } >, //custom compile time exceptions "Trix are for kids. Provide a username and password.", User >; // Ha! Silly Rabbit... function checkRabbit<T>(rabbit: ValidateRabbit<T>) { // .... protect your trix } declare const rabbit1: ValidRabbit; declare const rabbit2: InvalidRabbit; checkRabbit(rabbit1); checkRabbit(rabbit2); /** ~~~~~~~~~ * └───── Type Exception! "...Provide a username and password" */
您可以继续生活在恐惧中,为所有内容编写运行时检查,将 TypeScript 视为 JavaScript 的可选类型。
或者您可以在 2024 年加入我们,我们信任我们的编译器并让它完成其工作。
记住:每次你编写运行时类型检查时,TypeScript 编译器都会在某个地方哭泣。
Byzantium 不仅仅是另一个库——它是对类型信任问题的干预。是时候放弃运行时检查并拥抱编译时保证的力量了。
您的 CPU 会感谢您的。您的 DevOps 团队会感谢您。您的用户会感谢您(因为没有发现与类型相关的错误)。
最重要的是,你会在凌晨 3 点感谢自己,当时你睡得很熟,而不是在生产中调试类型错误。
P.S.如果您仍然不相信,请尝试计算代码库中有多少个运行时类型检查。然后乘以你的小时费率。这就是你花费了多少时间不信任 TypeScript。
P.P.S.在撰写这篇博文的过程中,没有人受到伤害。尽管一些运行时检查已永久停用。
*P.P.P.S。如果您想做出贡献,请访问我的 Github 并克隆该存储库。一切都还是新鲜的,所以有很多贡献的机会。
JSR.io 上提供的文档和包
以上是TypeScript 干预:使用 Byzantium 打破运行时检查成瘾的详细内容。更多信息请关注PHP中文网其他相关文章!