关于React的Container&Presentational Component模型结构分析

Clark

之前翻译了两篇关于Container&Presentational Component模型的文章,一篇是基础的Container和Component的定义,另外一篇是进阶版,因为翻译的太烂,感觉有很多错误,所以只放原文链接。

在这里我想讨论一下我自己对这个模型的一些想法。

注:便于书写,下面统一把Container&Presentational Components模型翻译为容器&展示组件模型

注:下面图片中的components文件夹指的是都是Presentational Components文件夹。


基于容器&展示组件模型的目录结构

Round 1:

刚接触React和这个模型的时候,我认为项目的结构应该是这样子的:
clipboard.png

  • Containers下面一个jsx文件就代表一个页面,负责和后台交互,负责和Redux进行connect,负责传递数据给component。在Router里面放入对应页面的Container

  • Components下面每个jsx文件就代表页面里面所有的渲染的内容,负责渲染,和把从container拿到的数据放到页面上

  • 顶多把一些基础的component分离出来,便于以后进行复用

可是才用两天,就知道这么搞有多么坑了。容器组件模型的目的就是复用性,可读性,可维护性,然而虽然我们很成功的把后台交互和页面展示分离开了,但是看到这么多代码放在一起,我没有感觉到任何复用性,可读性,可维护性,那么多代码,而且都混合了业务逻辑,你让我怎么复用,理解,维护?!
clipboard.png

Round 2:

痛定思痛,决定改一下,针对之前的问题,面向Component做出修改。基本的想法是这样子的:尽量拆分component,避免把所有的东西都放到一个文件里面; 拆出可复用的组件,便于组件的复用;拆分逻辑复杂的模块,增加模块的可读性和可维护性;所以关键字就是“拆、拆、拆”,拆出大好前程,拆出一片蓝天...

所以结构成了这样...
clipboard.png

整个代码结构复杂很多,不过主要的改变就是把基础组件分离出来(Sidebar, Form之类),每一个页面也精细化。我们可以更清晰的看出每个文件负责的功能,同时像Sidebar, Form这些组件都可以被多个不同的父组件调用。

当然,这不是结束,虽然上面的方法解决了我们可读性,可复用性,可维护性,但是也只针对Component的组件,在container中,依然会有很多的代码堆积在哪里

而且还有一个很严重的问题,先看一个代码逻辑结构图:

clipboard.png

我们现在的数据是通过Container来进行管理的,所以如果Images需要图片数据,那么就需要通过Container->Top->Slide->Images这样进行数据的传递,然而这些图片数据跟中间的组件没有任何关系,但是他们还必须把数据传递给下一级,就像公交车上,从后门递公交卡到前门刷一样,中间的人的心理OS其实是:

clipboard.png

当然代码是没有情感的,不会觉得厌烦,但是由于中间每一层都需要传递数据给下层,一旦某些数据发生改变,就造成了中间层级的重新render,浪费了浏览器性能的同时,增大了调试的难度,而且接收数据的组件还要考虑“中间那些牲口们有没有动我的数据”?!

Round 3:

所以,为什么一定要让顶级的container作为唯一的数据来源呢?

读了这篇文章就知道,Container是可以包含多个Container和Presentational Component的,所以我们可以适当的提升一些组件成为container。如果老板一个人直接管理很多员工,绝对会乱七八糟的,这个情况下,leader这个角色就应运而生,我们修改一下文件的结构:
clipboard.png

现在,代码的逻辑结构就变成这样子:
clipboard.png

作为老板的index.jsx,现在主要负责:

  • 页面的基础配置,比如页面的title,比如页面整体内容结构的配置

  • 页面全局的数据的获取和修改

作为leader的Top, Content,现在主要负责:

  • 和index.jsx进行沟通,获取基础配置和数据

  • 负责整合需要的container和component

  • 获取和处理自己对应模块的数据,并传递给下一层级

作为presentational component的组件,就负责获取数据并进行渲染

这么做的好处是,分离了原来顶层container的繁重的任务,使代码更加清晰。同时减少了从数据源到叶子结点的层级,减少了中间层级的数量和不必要的重复渲染。

当然,或许你会觉得之前举的那个栗子,只有index.js下面有一层container,或许中间节点还是太多。其实container里面可以包含container,根据需要,可以创建很多container在不同的层级上。

Round 4

View-Container-Presentational Component模型?这个名字是我自己编的,其实是对上面说的结构的一个分离。我也看到过有人说Page-Module-Component模型,反正大概思路都是一样的。

其实和上面的差不多,但是作为一个大老板来说,肯定不能和一堆下级员工混在一起,位置看起来有点混乱不说,"客人"(比如Router)来了,还不容易认。所以,我觉得应该给老板一个包间,让老板们在自己的包间中,听候客人的调遣。所以做出一点改动:
clipboard.png

Okay,这就是我的最终方案,相比于最早的结构,这个结构更清晰,每个模块负责的功能也更明确,代码可读性、可复用性和可维护性更高。

clipboard.png

最后自问自答环节

  • Container和Presentational Component的区别?

Container通常会负责和服务端的沟通,还有一些业务逻辑的处理。他们通常只负责获取数据,处理数据,处理状态,但一般不知道如何去展示页面。

Presentational Component通常不知道数据如何获取,也不知道这些数据是做什么用的,更不知道怎么去操作这些数据,他们一般只负责页面的渲染,把领导给的数据放到对应的位置。

当然一切都不是绝对的,容器组件模型只是一个指导思想,并不是一个硬性的规定,你可以按照自己的需要来进行改变。而且我在上面给了两个一般,也是说明这些不是绝对的。Container当然可以负责页面的展示,老板虽然大部分负责方向和管理,但谁规定老板就不能写代码的?!同样,Component也可以负责获取数据,举个栗子,一个地图的component,或者一个天气预报的component,他们可以从固定的地方获取数据,并把数据渲染出来。


  • Container可以包含Presentational Component?Presentational Component是否可以包含Container?

Container可以包含Container和Component。

但是Component一般不包含Container,虽然这篇文章的作者最后改口说,Component也可以包含Container,但是个人觉得应该保证component的纯净性,如果包含Container,那么就不再纯净,或许在复用的时候,会出现偏差的情况。

当然像我之前所说,一切都不是硬性规定,或许也只是因为我接触的少所以没有想到Presentational component需要包含container的情况,一切都根据自己的需要进行调整。


  • 如何知道什么时候要用container,什么时候要用Presentational component?

一般Presentational component应该是纯净(Pure)的,也就是说父级传给他的数据不变,那么渲染出来的结果也不应该发生任何变化。所以当一个组件需要业务逻辑处理,业务数据获取,那么可以考虑使用container。如果不需要这些东西,那么考虑使用Presentational component。当然,像之前所说的地图,天气预报,按照逻辑他们也属于component,但是他们也获取数据,处理数据。

当不知道该使用container还是Presentational component的时候,那么或许你在这个时候并不需要去决定这个问题。这种情况下,可以直接使用container来写,当你的container变得越来越复杂,代码量越来越多,逻辑越来越不清晰的时候,你就可以考虑分离处更多的container和Presentational component来。


  • 如果这篇文章指导的方向有错误,里面有很多的问题,该怎么办?

欢迎指出和讨论,一切问题都会认真回答,虚心接受。

如果我也答不出来,那我会当作没看到...
clipboard.png

阅读 6k

Clark's Blog
记录一些自己平时的想法

[链接]

3.4k 声望
78 粉丝
0 条评论
你知道吗?

[链接]

3.4k 声望
78 粉丝
宣传栏