专注的 React 技术栈成长路线

发布于 2022-04-25 12:58:46 字数 25869 浏览 1170 评论 0

当前学习重点,之一。忽然有了新的学习思路,学习新的技术,一个关键的因素是「技术的作者」。因此,这次学习路线上,会专注于列出与作者相关的学习资源:

资源的搜索方式:

  1. 通过 wiki,获取该框架的:作者、密切相关的第二作者或发言人、社区、会议
  2. 核心学习资料搜索:一二手发言人的开创性文章、官方文档兼快速入门、视频、Facebook、Twitter、Medium、"A cartoon intro to xxx" 等
  3. PKM 学习资料获取:社区 Youtube、会议 Youtube Channel、Medium 上相关 tag 的 RSS 订阅、最好两个聚合网站 邮件关注
  4. 不关注资料:各种聚合社区的三四五六手资料

总体路线构建

快速的 UI 构建:React

状态管理:Redux + Mobx

副作用消除:redux-saga + redux-thunk

路由管理:react-router

Observable:RxJS

Immutable #185

类型系统:TS

哎呀,可搞死葛格了。这个类型系统,是很好滴,直接可以用来表达 Tasking 里面数据输入输出项的类型。静态检查就能避免的 bug,没必要等到运行时嘛。这个流程大概是这样,ts 文件中的类型相关的信息先被 tsc 编译成 js,然后再经过 babel 转译成 ES5 代码。不能反过来,不然 babel 就算能搞出来 js/ts 代码 tsc 识别起来难度也很大;但这样要求 tsc 支持最基本/常见的 ES6/7 特性编译。

这个东西如何用到产品代码上,与 Webpack 等工具集成?如何用到测试代码上,与 mocha/jest 等本来就需要 parser/transpiler 的 loader 结合?如何与原来就集成了 Babel 等插件的 Eslint 再集成一次?等项目上有用到这个再探索。

测试:Enzyme + power-assert + jest + sinon

「测试」话题的核心,主要有两个:测试先行还是后行,以及怎么做测试的问题。

测试先行还是后行,不强求,先行的方式就是 TDD。这个问题域实际是整个 TDD 论域的问题。下面是我对 TDD 思考的一整个系列,自知算不上特别的声音,但好歹是自己的思考,对自己的认识成长过程是有意义的。里面也给出了通往经典的链接:

怎么测,TDD 的实践问题。这部分只要查 API 就好了。对于单元测试来说,一般就是 直接测、mock 测 两部分的 API 而已。之所以选 power-assert 这个断言库,一个是因为简洁而不简单的 API,支持基本类型对比、复杂类型对象深对比;一个是因为提示信息极为友好。

构建工具与包管理:webpack 3 + npm 5 + yarn

React Native


哎呀,你这几个问题,我探索了一番,总结下我的感受:

  • 断言对比:API 和语法上差异不大,Power-assert 的断言库似乎缺少 partial 比对,在某些(比如我们的)项目背景上可能有问题
  • 提示信息:Jest 可以支持深对象的可视化比对(click to see difference),power-assert 对于多层对象获取(access)的中间值均可以打印出来
  • IDE 结合:不能直接跳到出错的产品代码处

断言对比

APIJestpower-assert
简单值类型比对expect(received).toBe(expected)assert.equal(received, expected)
复杂对象类型比对expect(received).toEqual(expected)assert.deepEqual(received, expected)
数组长度比对expect(received).toHaveLength(expected)assert.equal(received.length, expected)
部分对象比对expect(received).toMatchObject(expected)没找到

API 上即便有微小的差别,我觉得也不大。部分对象比对这个事情,我感觉也是有所保留的技术,有「选择性」地仅测试比对某部分对象,这个「选择性」的算法对于测试结果有无影响,就是不太好说准的事情,比如是否存在可使测试通过但不合场景的其他对象切片?当然它换得了相对宽松的比对环境,对于一些复杂代码或大型代码的场景可能有很好的收益。但相比其潜在复杂性,我觉得它似乎是对极简测试这个理念带来了额外的负担。换句话说,测试挂了,你怎么知道是测试写错挂了,还是「部分比对」的这个逻辑挂了?测试过了,你怎么知道其他的错误组合是否也能让测试通过?

很巧我们项目就有这样的使用场景,我们的 reducer 测试返回了整个 state,不进行部分比对,测试就没法写了。

提示信息

分三类:简单类型比对的提示信息、简单对象比对的提示信息,以及复杂对象比对的提示信息。

简单类型比对

Jest

Power-assert

简单对象比对

Jest

Power-assert

复杂对象比对

Jest

Power-assert

power-assert 能支持的是打印中间每一步的值,这个对于判断在获取期望值的中间是否就已经出现了空值或类型错误很有帮助。它不支持 click to see difference,在对象比对时给出的差异比对也没有 jest 直观。

在 jest 支持 click to see difference,这个比对结果就非常可视化了(我猜这也是 power-assert 尝试打印中间值希望获得的结果——过程的可视化,可似乎在复杂对象的领域表现不佳)。尽管这个可视化的理念很好,但是 click 这个动作依然不敏捷,希望双方能有更好的解决方案。

IDE 支持

直接跳到出错代码。这个双方都不支持。静静见过什么工具支持这个嘛[Smirk]

所以回顾起来,断言过程可视化 和 断言结果差异可视化 都是很有价值的反馈方式,前者目前在复杂对象的情景下形同没用(见下图,一堆木用的信息),后者需要一次鼠标点击。API 差别不大的情况下,我觉得对象结构较简单的项目可以用 power-assert,充分利用这个可视化的断言过程比对;对象结构复杂、需求复杂的项目可以用 jest,获得相对更好的差异比对体验。


个人觉得对于 power-assert,应该这样用更直观:

APIJestpower-assert
简单值类型比对expect(received).toBe(expected)assert(received === expected)
复杂对象类型比对expect(received).toEqual(expected)assert.deepEqual(received, expected)
数组长度比对expect(received).toHaveLength(expected)assert(received.length === expected)
部分对象比对expect(received).toMatchObject(expected)assert.deepEqual({attr1: received.attr1, attr2: received.attr2}, {attr1: expected.attr1, attr2: expected.attr2})

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据

关于作者

JSmiles

生命进入颠沛而奔忙的本质状态,并将以不断告别和相遇的陈旧方式继续下去。

0 文章
0 评论
84961 人气
更多

推荐作者

已经忘了多久

文章 0 评论 0

15867725375

文章 0 评论 0

LonelySnow

文章 0 评论 0

走过海棠暮

文章 0 评论 0

轻许诺言

文章 0 评论 0

信馬由缰

文章 0 评论 0

    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文