继续聊聊MVVM和组件化

上次说到MVVM，MVVM其实是MVC的变种，它让把C分配给了V和VM，然后就出现了组件和store，这样写可以让视图更好的交互，让数据更好的服务。而MVVM的创始人John Gossman也说了

实现MVVM的开销对于简单的UI操作是“过度的”。他说，对于更大的应用来说，推广ViewModel变得更加困难。而且，他说明了非常大的应用程序中的数据绑定会导致相当大的内存消耗。

这句话很好理解，MVVM对于写个博客系统或者后台管理系统来说是过度的，没必要，还费内存。但对于前端分离的开发，和越来越高的用户体验要求以及电脑内存越来越大，这句话我个人觉得已经过时了。

作为一个有追求的前端开发，理所当然更加注重用户体验了，而且面向未来的看，很快2G内存的笔记本都比较罕见了，放开200M内存一个页面也很难烧完。

react提供了自上而下的state和props来表达网站的状态的功能，但在大多数网站里边，redux或者mobx通常回去充当VM。

mobx对后端很友好

对于深爱store的原因，有很多。

用了很久之后，我发现MVVM的一个超级大的好处，就是背锅。

这个背锅怎么理解呢，就是在前后端分离的项目里边，面对规范并不严格或者或者js配合不算舒服的一些后端语言对接接口，store可以很轻松的抗下来，几乎不会显得难受。即便后端不会模块化，我们仍然可以用mobx实现一个完备的模块化数据集合，最后再用store去给组件提供最舒服的数据，那么开发组件的时候就会很愉快了。

也就是说我们从store里取数据，然后用store更新数据，把数据放在store里就好了。

为什么用store代替state，可以读一下这篇文章 我用Store代替setState的三个原因 。

文章主要内容是这样的

1. setState是异步的

2. setState会造成没必要的渲染

3. setState还会触发一些无关紧要的life cycle。

其实使用mobx控制数据很爽，很统一一致，让数据管理变得十分容易。相比之下更重要的是，

mobx对产品经理很友好

这句话怎么理解呢，就是说全局的状态管理机制让数据一直保持在外层，我们只是在变花样的去调用它而已。那么面对产品的需要，我们可以很容易的通过改变数据的调用方式而重构业务。

最后说了一下做为V的React。

用了react之后的第一件事就是告诉自己你应该习惯用一种新的方式表达你的网站了，这也是react比vue的学习曲线陡峭的原因，react希望使用者用一种全新的方式描述和表达网站，而vue的模板亲和力更高一点。

网站的描述和表达是什么意思呢，就是说写网站就像在写文章一样，只是这次我们用的语言不是汉语，英语，而是javascript，没有react之前我们写网站也是在描述网站，但很low啊，我们在用html描述

而react是换了一种方式描述网站，用有状态和生命周期的组件去描述网站，我觉得当理解这一层的时候，那么就会找到新的做前端的感觉，水平也会有质的提升。就像我天天在吐槽后端一样，你们不要管业务，你们的视野应该放在数据上，应该怎么去更好的提供数据。前端也一样，视野应该放在如何去管理数据，表达UI和交互，而不是如何完成业务。

粗旷的说组件只有两种，业务组件和UI组件。

UI组件是和业务无关的组件，主要是帮助设计师解决的问题的。

业务组件是封装产品功能，主要是帮助产品经理解决问题的。

UI组件库必须要做，没有UI组件库React写页面的能力会掉百分之七八十，大多数前端虽然理解UI的能力不够强，但还是去积极的做吧，这点可以从本质上提升你的React水平。

功能组件和 工具 类组件

大多数人对组件的理解都只是UI层面的，在高级一点就是弹窗之类了，react一切都是组件，路由都是组件，组件并不是UI，组件可以是任何东西，理解了js一切都是对象，函数是一等公民，那么这点也很容易理解了。react让复杂多变的UI界面更容易表达。

不管是不是可以复用，都去拆分组件，按照数据和功能拆分组件

一个错误的示范

<Page>
 {this.renderSearch()}
 {this.renderFilter()}
 {this.renderList()}
</Page>复制代码

一个正确的示范

<Page>
  <Search/>
  <Filter/>
  <List/>
</Page>复制代码

但是可以有比较多的可选参数支持更多的配置

react-router v4的特点就是抛弃以前静态路由的僵局，迎合react的本质一切都是组件。

减少componentWillMount componentWillUpdate的使用，props驱动state，这个是getDerivedStateFromProps的本质。

当可以做到以上的这些之后，你会发现开发变得越来越简单，越来越流畅，然后嚣张到变形，你会觉得产品的需求可能不够复杂，设计图太无聊了，后端给的数据还是挺不错的。这个时候需要考虑的一个很关键的问题就是优化，当然优化还是早点考虑，但是对于强大的计算机计算来说，小小的优化可能并不会造成感官上的用户体验，但是保证良好的优化习惯，积少成多，迟早会有质的飞跃的。

如果可以react提供了shouldComponentUpdate来判断是否应该渲染

很多场合计算并不需要放在render里，会造成不必要的计算

越往底层的组件越需要成为PureComponent

React的精华所在，通过公用组件库来提升整个项目的开发效率，但是这个前提是 良好的编码习惯，高性能的编码习惯以及长期坚持封装组件和对用户体验的追求。

最后说到了视野，我觉得大多数人的视野并不开阔，是因为他只能看到眼前的利益。

举几个栗子：

1. 比方说去写组件库这个东西花费了本来完成业务所用时间的1.4倍，但是下次下下次他会缩短完成业务所用时间到本应该的0.5倍。
2. 用store代替state可以让产品业务越来越容易写，虽然要管理和构建一个复杂的数据系统，只要开头了，剩下的只是习惯而已。
3. 花1天的时间修一下webpack，可能会让自己的开发更新时间快一倍以上。当然即使快0.2倍我也愿意去花这一天的时间。
4. 规范也很重要，最佳实践也很重要，这些对效率的提升更难表现出来。最佳实践这个词听起来很决绝，凭什么是最佳。对，我很喜欢那些不遵循最佳实践的人，但是是那种可以很好理解所谓最佳实践意义的人。
5. 关于拖延症，每个人都有，我现在就拖延睡觉到1点半了，但是面对写代码，对自己对别人可以严格一点，可以认为这是作为 程序员 的工匠精神。

日漫里的名言，所有悲剧的发生都是缘于当事人的能力不足。这句话看起来很粗鄙的在排除各种因素，归结为人的因素，但仔细回味起来却很深奥。

最后希望所有的读者可以按照更好的实践和规范去践行所做的事，遇到问题及时更正，以免推到无法挽回的地步。