《深入浅出React和Redux》读书笔记一

weiqi 2019-06-21

  • 使用React.createClass是一种过时的方法
  • React 判断一个元素是HTML元素还是React组件的原则就是看第一个字母是否大写
  • 在HTML中直接写onclick一直就是为人诟病的写法,网页应用开发界一直倡导的是用jQuery的方法添加事件处理函数,直接写onclick会带来代码混乱的问题
  • 既然长期以来不倡导在HTML中使用onclick,为什么在React的JSX中我们却要使用onClick这样的方式来添加事件处理函数呢?
  • 以前使用HTML来代表内容、用CSS代表样式、用JavaScript来定义交互行为,这三种语言分在三种不同的文件里面,实际上是把不同的技术分开管理了,而不是逻辑上的"分而治之"
  • 根据做同一件事的代码应该有高耦合性的设计原则,既然我们要实现一个Click-Counter,那为什么不把实现这个功能的所有代码集中在一个文件里呢?
  • 即使现在,我们还是要说在HTML中直接使用onclick很不专业,原因如下:

    • onclick 添加的事件处理函数是在全局环境下执行的,这污染了全局环境,很容易产生意料不到的后果;
    • 给很多DOM元素添加onclick事件,可能会影响网页的性能,毕竟,网页需要的事件处理函数越多,性能就会越低;
    • 对于使用onclick的DOM元素,如果要动态地从DOM树中删除的话,需要把对应的事件处理器注销,如果忘了注销,就可能造成内存泄漏,像这样的Bug很难被发现
    • 上述的这些问题,在JSX中都不存在
  • 因为

    • JSX中一个组件使用了onClick,并没有直接使用onclick的HTML,而是使用了事件委托(event delegation)的方式处理事件,无论有多少个onClick出现,其实最后都只在DOM树上添加了一个事件处理函数,挂在最顶层的DOM节点上;
    • 所有的点击事件都被这个事件处理函数捕获,然后根据具体组件分配给特定函数,使用事件委托的性能当然要比为每个onClick都挂载一个事件处理函数要高;
    • 因为React控制了组件的生命周期,在unmount的时候自然能够清楚相关的所有事件处理函数,内存泄漏也不再是一个问题;
  • 选取一些DOM元素,然后对这些元素做一些操作,这是一种最容易理解的开发模式;jQuery的发明人John Resig就是发现了网页应用开发者的这个编程模式,才创造出了jQuery,其一问世就受到普遍认可,因为这种模式直观易懂。但是,对于庞大的项目,这种模式会造成代码结构复杂,难以维护,每个jQuery的使用者都会有这种体会
  • 用React开发的ClickCounter组件并没有像jQuery那样做"选中一些DOM元素然后做一些事情的动作"

打一个比方,React是一个聪明的建筑工人,而jQuery是一个比较傻的建筑工人,开发者你就是一个建筑的设计师,如果是jQuery这个建筑工人为你工作,你不得不事无巨细地告诉jQuery“如何去做”,要告诉他这面墙要拆掉重建,那面墙上要新开一个窗户,反之,如果是React这个建筑工人为你工作,你所要做的就是告诉这个工人“我想要什么样子”,只要把图纸递给React这个工人,他就会替你搞定一切,当然他不会把整个建筑拆掉重建,而是很聪明地把这次的图纸和上次的图纸做一个对比,发现不同之处,然后只去做适当的修改就完成任务了。
显而易见,React的工作方式把开发者从繁琐的操作中解放出来,开发者只需要着重“我想要显示什么”,而不用操心“怎样去做”。
这种新的思维方式,对于一个简单的例子也要编写不少代码,感觉像是用高射炮打蚊子,但是对于一个大型的项目,这种方式编写的代码会更容易管理,因为整个React应用要做的就是渲染,开发者关注的是渲染成成什么样子,而不用关心如何实现增量渲染。
React的理念,归结为一个公式,就像下面这样:
UI=render(data)
让我们来看看这个公式表达的含义,用户看到的界面(UI),应该是一个函数(在这里叫render)的执行结果,只接受数据(data)作为参数。这个函数是一个纯函数,所谓纯函数,指的是没有任何副作用,输出完全依赖于输入的函数,两次函数调用如果输入相同,得到的结果也绝对相同。如此一来,最终的用户界面,在render函数确定的情况下完全取决于输入数据。

相关推荐