专注的 React 技术栈成长路线
当前学习重点,之一。忽然有了新的学习思路,学习新的技术,一个关键的因素是「技术的作者」。因此,这次学习路线上,会专注于列出与作者相关的学习资源:
资源的搜索方式:
- 通过 wiki,获取该框架的:作者、密切相关的第二作者或发言人、社区、会议
- 核心学习资料搜索:一二手发言人的开创性文章、官方文档兼快速入门、视频、Facebook、Twitter、Medium、"A cartoon intro to xxx" 等
- PKM 学习资料获取:社区 Youtube、会议 Youtube Channel、Medium 上相关 tag 的 RSS 订阅、最好两个聚合网站 邮件关注
- 不关注资料:各种聚合社区的三四五六手资料
总体路线构建
- 补全《不吹不黑》中提到的前端体系结构
- 云龙关于职业规划的分享 一个程序员的成长之路 fouber/blog#41
- 大公司里如何开发和部署前端代码 https://www.zhihu.com/question/20790576/answer/32602154
- https://zhuanlan.zhihu.com/p/32782686
快速的 UI 构建:React
- 作者:Jordan Walke, Facebook and Instagram from wiki: React
- 相关会议:JSConf, ReactConf, 会议列表
- 综述文章:https://thenewstack.io/javascripts-history-and-how-it-led-to-reactjs/
- 官方推荐:
- 文档 Getting Started & Advanced Guides: https://facebook.github.io/react/docs/hello-world.html
- Wiki: https://github.com/facebook/react/wiki/Articles-and-Videos
- 唯一一个在线课程:https://learn.tylermcginnis.com/courses/enrolled/50507
- React + ES6: https://babeljs.io/blog/2015/06/07/react-on-es6-plus
- 最新讨论中信息:
- Core team 讨论区:https://discuss.reactjs.org/c/meeting-notes
- react-future: https://github.com/reactjs/react-future
- Feature Request: https://github.com/facebook/react/labels/Type:%20Feature%20Request
- 我未完的笔记:1. 纯 React 技术目录 #122
状态管理:Redux + Mobx
- 作者:Dan Abramov from wiki: Redux
- 来源
- Flux
- Elm
- 起源:2015年作者在 Conf 上的演讲,一举成名:https://www.youtube.com/watch?v=xsSnOQynTHs
- 作者自己写的综述:https://news.ycombinator.com/item?id=13201532
- Github Issue, Single store approach of redux: What are the disadvantages of storing all your state in a single immutable atom? reduxjs/redux#1385
- 官方推荐
- 文档 介绍、基础、进阶。是块宝,通读之:http://redux.js.org/docs/introduction/index.html
- 作者视频1 Getting Started with Redux: https://egghead.io/courses/getting-started-with-redux
- 作者视频2 Building React Applications with Idiomatic Redux: https://egghead.io/courses/building-react-applications-with-idiomatic-redux
- 用不用 Redux:https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367
- 静静的总结:Learning-Redux 着重数据结构设计与数据流,处理异步请求 JimmyLv/jimmylv.github.io#16
- 我未完的笔记:React 栈(二):Redux #142
副作用消除:redux-saga + redux-thunk
- redux-thunk & redux-saga
- 作者:又是 Dan 这老哥。react-saga 没找到作者
- 作者综述:你为什么(不)需要 react-thunk:https://stackoverflow.com/questions/35411423/how-to-dispatch-a-redux-action-with-a-timeout/35415559#35415559
- redux-thunk 和 redux-saga 的动机与不同:https://hashnode.com/post/what-are-the-benefits-of-redux-thunk-over-redux-saga-what-pros-and-cons-do-they-have-over-each-other-ciqvyydh7065w3g53ffalif61
- 另外一篇 Google 排名靠前心一软就拿进来的综述:https://medium.com/@stowball/a-dummys-guide-to-redux-and-thunk-in-react-d8904a7005d3
- 其他的没有了。主要靠看
README
和实践了
路由管理:react-router
- 作者:Michael Jackson & Ryan Florence
- 什么时候用 React Router: https://medium.freecodecamp.org/you-might-not-need-react-router-38673620f3d 。都快成类型文了
- 两位作者的视频:
- https://www.youtube.com/watch?v=Vur2dAFZ4GE
- Learn Once, Route Anywhere: https://www.youtube.com/watch?v=Mf0Fy8iHp8k
- Ryan Florence Introduction to React Router V4: https://www.youtube.com/watch?v=a4kqMQorcnE
Observable:RxJS
Immutable #185
- ImmutableJS 作者 Lee Byron
- Redux Documentation:
- Immutable Data: http://redux.js.org/docs/faq/ImmutableData.html
- Using ImmutableJS: http://redux.js.org/docs/recipes/UsingImmutableJS.html
- React.js Conf 2015 - Immutable Data and React with Lee Byron: https://www.youtube.com/watch?v=I7IdS-PbEgI
- Immutable User Interfaces (Lee Byron) - Full Stack Fest 2016: https://www.youtube.com/watch?v=pLvrZPSzHxo
- Devchat 243 JSJ Immutable.js with Lee Byron: https://overcast.fm/+B1TFAefyQ
- 综述型文章:讲 Immutability 的一些优点和缺点:http://reactkungfu.com/2015/08/pros-and-cons-of-using-immutability-with-react-js/
- React 有关 immutable 的一些 anti-pattern: https://medium.com/@esamatti/react-js-pure-render-performance-anti-pattern-fb88c101332f
- https://auth0.com/blog/intro-to-immutable-js/
类型系统: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 回炉重造 #157
- TDD 二回炉 #176
- TDD 周报三「作为个人工具和团队实践的 TDD」 #177
- TDD 周报四「TDD 是一门艺术,不是科学」 #178
- TDD 周报五「TDD 是敏捷实践的灵魂」 #179
- TDD 周报六「结语 - 我们为什么不用 TDD」 #181
怎么测,TDD 的实践问题。这部分只要查 API 就好了。对于单元测试来说,一般就是 直接测、mock 测 两部分的 API 而已。之所以选 power-assert 这个断言库,一个是因为简洁而不简单的 API,支持基本类型对比、复杂类型对象深对比;一个是因为提示信息极为友好。
构建工具与包管理:webpack 3 + npm 5 + yarn
- webpack
- 作者:Sokra(核心开发), Juho Vepsäläinen(负责文档), Sean Larkin(负责公关)
- 作者自己的综述性文章:https://medium.com/webpack/webpack-its-getting-real-92c60fca1db1
- 作者视频:https://www.youtube.com/watch?v=TUtc3p8Z9a8&list=PLRDU4UY3L4pZ_XiQCFTv5Lz1ZDAPPikWl
- 作者之一 Sean Larkin 的免费课程:https://webpack.academy/courses/enrolled/104961
React Native
- 没有第一作者
- 官方文档:https://facebook.github.io/react-native/
- 最好的教程来自 @JimmyLv :http://www.reactnativeexpress.com/
- http://www.awesome-react-native.com/
- Tyler McGinnis 的课程应该可信赖:https://egghead.io/courses/react-native-fundamentals
- Quora 有人推荐这个课程很不错:https://www.udemy.com/the-complete-react-native-and-redux-course/?altsc=610300
- 用 Tinder 实例学 React Native 课程:https://cloneable.io/
哎呀,你这几个问题,我探索了一番,总结下我的感受:
- 断言对比:API 和语法上差异不大,Power-assert 的断言库似乎缺少 partial 比对,在某些(比如我们的)项目背景上可能有问题
- 提示信息:Jest 可以支持深对象的可视化比对(click to see difference),power-assert 对于多层对象获取(access)的中间值均可以打印出来
- IDE 结合:不能直接跳到出错的产品代码处
断言对比
API | Jest | power-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,应该这样用更直观:
API | Jest | power-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 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论