听着，我们需要谈谈你的类型检查瘾。是的，就是您——在您的身份验证中间件中进行了 47 个instanceof 检查。编写的测试用例多于实际代码的开发人员。将 typescript 视为只是花哨的 jsdoc 注释的人。
干预
让我给你画一幅图画：现在是中午，你正在喝第四杯咖啡，并且正在调试一个生产问题。日志显示用户以某种方式通过了十五层运行时验证。你的单元测试比 twitter 的活跃用户还要多，但不知何故，不知何故，有人设法在应该是字符串的地方发送了一个数字。
“但那是不可能的！”你哭了，滚动浏览测试覆盖率报告，显示原始的 100%。 “我检查过这个！”
你有吗？你真的吗？或者您是否只是将同一张支票写了三遍：
进入 typescript 界面再次在您的验证中间件中再次在单元测试中
停止测试 typescript 已经知道的内容
这是一个革命性的想法：如果我们……信任编译器会怎样？我知道，疯狂的概念。但请听我说完。
interface validrabbit { username: string; password: string;}interface invalidrabbit { username: number; password: string;}type validaterabbit = assert< //assert that rabbit is of type {username, password} is.type, //custom compile time exceptions "trix are for kids. provide a username and password.", user>;// ha! silly rabbit...function checkrabbit(rabbit: validaterabbit) { // .... 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 boundariestype apirequest = assert< and< is.on, or<is.in, is.in>>;, "someone's being naughty with our api">;// now everything inside is type-safefunction handlerequest(req: apirequest) { // if it compiles, it's valid // if it's valid, it compiles // this is the way}
devops 团队会爱你（一次）
想象一下：您的 ci/cd 管道在几分钟内完成，而不是几小时。您的生产日志中不会充满类型错误。您的 aws 账单看起来不像电话号码。
怎么样？因为拜占庭将类型检查移至编译时。没有了：
运行数千个仅检查类型的单元测试消耗 cpu 周期一遍又一遍地检查相同的类型凌晨 3 点醒来，因为有人将 undefined 传递给一个明确表示需要字符串的函数
// before: your cpu crying for helpfunction 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 notetype validrequest = assert< and< is.on, is.on, is.on, is.on >, "invalid request shape">;function handlerequest(req: validrequest) { // just business logic, no trust issues}
“但我喜欢写测试！”
伟大的！为真正需要测试的东西编写测试：
业务逻辑整合点用户工作流程复杂算法
你知道什么不需要测试吗？字符串是否实际上是字符串。让 typescript 来处理这场生存危机。
真实的谈话：好处
更快的发展
不再用三种不同的方式编写相同的验证在编译时捕获错误，而不是在凌晨 3 点花时间在功能上，而不是验证样板
更好的性能
类型检查的零运行时开销更小的包大小（无验证库）快乐的cpu，快乐的生活
提高安全性
类型级保证无法被绕过不再有“哎呀，忘了验证”默认完全覆盖
devops 梦想
更快的 ci/cd 管道降低基础设施成本生产事故减少sre 团队更快乐（结果可能会有所不同）
入门
$ npx jsr add @constantine/byzantium#or$ deno add jsr:@constantine/byzantium#or$ pnpm dlx jsr add @constantine/byzantium# ... and yarn, and whatever other package manager# Now go delete half your test suite
选择是你的
您可以继续生活在恐惧中，为所有内容编写运行时检查，将 typescript 视为 javascript 的可选类型。
或者您可以在 2024 年加入我们，我们信任我们的编译器并让它完成其工作。
记住：每次你编写运行时类型检查时，typescript 编译器都会在某个地方哭泣。
结论
byzantium 不仅仅是另一个库——它是对类型信任问题的干预。是时候放弃运行时检查并拥抱编译时保证的力量了。
您的 cpu 会感谢您的。您的 devops 团队会感谢您。您的用户会感谢您（因为没有发现与类型相关的错误）。
最重要的是，你会在凌晨 3 点感谢自己，当时你睡得很熟，而不是在生产中调试类型错误。
p.s.如果您仍然不相信，请尝试计算代码库中有多少运行时类型检查。然后乘以你的小时费率。这就是你花费了多少时间不信任 typescript。
p.p.s.在撰写这篇博文的过程中，没有人受到伤害。尽管一些运行时检查已永久停用。
*p.p.p.s。如果您想做出贡献，请访问我的 github 并克隆该存储库。一切都还是新鲜的，所以有很多贡献的机会。
jsr.io 上提供的文档和包
以上就是TypeScript 干预：使用 Byzantium 打破运行时检查成瘾的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1494492.html
微信扫一扫 
支付宝扫一扫 
