周报（2018-12-07）

[yinguangyao]

这周正式开始做IBU项目，虽然之前用mobx和typescript写过demo，但毕竟没有在项目中用过。

关于RN

由于我们这边是CSS和JS分岗的形式，所以RN的样式也是由CSS组写好组件一起给我们，这和以前开发H5，他们直接给我们coding稿很不一样。 以前我们可以在chrome里面查看coding稿的html结构和样式，可以自己去封装react组件。 现在都是他们封装了组件，但是由于CSS组不是专门写JS的，他们封装的组件会有一些不合理，其次我们无法看到页面的整体结构，没法很容易地知道某个组件对应了页面上哪一部分，这样极大的增加了工作量和沟通成本。

关于TypeScript

做IBU之前打算上TypeScript，我只是觉得很新鲜，一直想学新技术。在研究了一段时间后发现这个东西对代码的日后维护和重构有很大帮助，增加了静态类型，但又允许你使用any，保证类型检查的同时又保证了灵活度。 除了类型之外，我觉得TypeScript在一定程度上改变了我的编程思维。老实说，我以前写的代码既不是面向对象，又不是函数式，最多只能叫面向过程，我也不懂为什么要用面向对象。 因为这期用到了Mobx和TypeScript，我才思考面向对象的意义和重要性，因此我也去接触了不少的设计模式，遇到老代码里面的某些场景，我会思考这个适合哪种设计模式，我可以来重构和解耦。 由于TypeScript的语法和c#、java比较像，这也让我可以去阅读一些java相关的文章，以前看不懂那些语法，现在可以大致看懂语法后理解一些后端编程的思想，并且运用到前端上面。

关于FSM

今天在做酒店列表页下拉加载的时候，突发奇想，酒店列表页下拉加载的时候一共有loading、fail、finish三种状态，其中对应关系只有loading -> fail，fail -> loading，loading -> finish，这不就是很符合状态机的思想吗？ 于是我想起了javascript-state-machine这个库，后来翻阅了一下github上的用法，但是发现很难和Mobx结合到一起，与其舍近求远强行用上这个库，还不如不用。 后来我想了想，既然不用这个库，但是这个思想还是很值得借鉴的，我完全可以基于自己的业务封装一下这个功能，但是暂时也没有发现这个解决了什么问题，价值还是待定。

总结

总之，这周虽然写的进度很慢，目前只把页面store和组件设计好，但是也学到了不少的东西。与其低质量的赶工，我更愿意花更多时间来高质量的完成任务。

[SHERlocked93]

状态机这个后来用到了么

[yinguangyao]

@SHERlocked93 事实是没有用到，我感觉还是场景问题，状态机适合只有几个状态来回切换的那种场景。