摘要：同时减少了从数据源到叶子结点的层级，减少了中间层级的数量和不必要的重复渲染。模型这个名字是我自己编的，其实是对上面说的结构的一个分离。当然，像之前所说的地图，天气预报，按照逻辑他们也属于，但是他们也获取数据，处理数据。
之前翻译了两篇关于Container&Presentational Component模型的文章，一篇是基础的Container和Component的定义，另外一篇是进阶版，因为翻译的太烂，感觉有很多错误，所以只放原文链接。
在这里我想讨论一下我自己对这个模型的一些想法。
注：便于书写，下面统一把Container&Presentational Components模型翻译为容器&展示组件模型
注：下面图片中的components文件夹指的是都是Presentational Components文件夹。
基于容器&展示组件模型的目录结构 Round 1:刚接触React和这个模型的时候，我认为项目的结构应该是这样子的：
Containers下面一个jsx文件就代表一个页面，负责和后台交互，负责和Redux进行connect，负责传递数据给component。在Router里面放入对应页面的Container
Components下面每个jsx文件就代表页面里面所有的渲染的内容，负责渲染，和把从container拿到的数据放到页面上
顶多把一些基础的component分离出来，便于以后进行复用
可是才用两天，就知道这么搞有多么坑了。容器组件模型的目的就是复用性，可读性，可维护性，然而虽然我们很成功的把后台交互和页面展示分离开了，但是看到这么多代码放在一起，我没有感觉到任何复用性，可读性，可维护性，那么多代码，而且都混合了业务逻辑，你让我怎么复用，理解，维护？！
痛定思痛，决定改一下，针对之前的问题，面向Component做出修改。基本的想法是这样子的：尽量拆分component，避免把所有的东西都放到一个文件里面; 拆出可复用的组件，便于组件的复用；拆分逻辑复杂的模块，增加模块的可读性和可维护性；所以关键字就是“拆、拆、拆”，拆出大好前程，拆出一片蓝天...
所以结构成了这样...
整个代码结构复杂很多，不过主要的改变就是把基础组件分离出来(Sidebar, Form之类)，每一个页面也精细化。我们可以更清晰的看出每个文件负责的功能，同时像Sidebar, Form这些组件都可以被多个不同的父组件调用。
当然，这不是结束，虽然上面的方法解决了我们可读性，可复用性，可维护性，但是也只针对Component的组件，在container中，依然会有很多的代码堆积在哪里。
而且还有一个很严重的问题，先看一个代码逻辑结构图：
我们现在的数据是通过Container来进行管理的，所以如果Images需要图片数据，那么就需要通过Container->Top->Slide->Images这样进行数据的传递，然而这些图片数据跟中间的组件没有任何关系，但是他们还必须把数据传递给下一级，就像公交车上，从后门递公交卡到前门刷一样，中间的人的心理OS其实是：
当然代码是没有情感的，不会觉得厌烦，但是由于中间每一层都需要传递数据给下层，一旦某些数据发生改变，就造成了中间层级的重新render，浪费了浏览器性能的同时，增大了调试的难度，而且接收数据的组件还要考虑“中间那些牲口们有没有动我的数据”？！
Round 3:所以，为什么一定要让顶级的container作为唯一的数据来源呢？
读了这篇文章就知道，Container是可以包含多个Container和Presentational Component的，所以我们可以适当的提升一些组件成为container。如果老板一个人直接管理很多员工，绝对会乱七八糟的，这个情况下，leader这个角色就应运而生，我们修改一下文件的结构：
现在，代码的逻辑结构就变成这样子：
作为老板的index.jsx，现在主要负责：
页面的基础配置，比如页面的title，比如页面整体内容结构的配置
页面全局的数据的获取和修改
作为leader的Top, Content，现在主要负责:
和index.jsx进行沟通，获取基础配置和数据
负责整合需要的container和component
获取和处理自己对应模块的数据，并传递给下一层级
作为presentational component的组件，就负责获取数据并进行渲染
这么做的好处是，分离了原来顶层container的繁重的任务，使代码更加清晰。同时减少了从数据源到叶子结点的层级，减少了中间层级的数量和不必要的重复渲染。
当然，或许你会觉得之前举的那个栗子，只有index.js下面有一层container，或许中间节点还是太多。其实container里面可以包含container，根据需要，可以创建很多container在不同的层级上。
Round 4View-Container-Presentational Component模型？这个名字是我自己编的，其实是对上面说的结构的一个分离。我也看到过有人说Page-Module-Component模型，反正大概思路都是一样的。
其实和上面的差不多，但是作为一个大老板来说，肯定不能和一堆下级员工混在一起，位置看起来有点混乱不说，"客人"(比如Router)来了，还不容易认。所以，我觉得应该给老板一个包间，让老板们在自己的包间中，听候客人的调遣。所以做出一点改动：
Okay，这就是我的最终方案，相比于最早的结构，这个结构更清晰，每个模块负责的功能也更明确，代码可读性、可复用性和可维护性更高。
最后自问自答环节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来。
如果这篇文章指导的方向有错误，里面有很多的问题，该怎么办？
欢迎指出和讨论，一切问题都会认真回答，虚心接受。
如果我也答不出来，那我会当作没看到...
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/86590.html
摘要：在线注册账号，数据存储于。年了，还不使用的异步控制体系。过度对数据模型进行装饰的结果便是高耦合，这跟我初衷是基于在线存储数据有关。 为什么又是Todo，全世界的初学者都在做todo吗？可能很多人要问这句话，其实这句话可以等同于： 为什么你做了个云音乐播放器？ 为什么你做了个新闻阅读APP？ 为什么你做了个VUE/REACT版本的CNODE？ 究其本质，这几个应用都是data-map...
摘要：对于很多中间组件来说，他们并不需要这些，但是他们还必须传递给下一级组件。更倾向于，而更倾向于，当然这并不是绝对的。这是篇文章翻译自的 这是篇文章翻译自medium的：Presentational and Container Components 译者语：这篇文章是紧接着对我上一篇翻译的扩充，对Container Component模式描述的更加细，解决了我很多开发中的困惑。 Prese...
摘要：在一个应用中，如何通过和端进行交互这个问题曾经困扰了我一段时间，经过学习实践，有了一点心得体会，写出来和大家分享一下。组件和一样，和进行交互，将获取的通过向下传递给组件。不足被设计用来和服务器一起运行，并不能很好的和第三方服务交互。 在一个react应用中，如何通过ajax和server端进行交互这个问题曾经困扰了我一段时间，经过学习实践，有了一点心得体会，写出来和大家分享一下。 总的...
摘要：如在中在中，聚合积累的结果是当前的对象。被称为副作用，在我们的应用中，最常见的就是异步操作。至于为什么我们这么纠结于纯函数，如果你想了解更多可以阅读，或者它的中文译本函数式编程指南。 DvaJS： React and redux based, lightweight and elm-style framework. https://dvajs.com/ 实例项目源码：https://g...
摘要：更多相关介绍请看这特点仅仅只是虚拟最大限度减少与的交互类似于使用操作单向数据流很大程度减少了重复代码的使用组件化可组合一个组件易于和其它组件一起使用，或者嵌套在另一个组件内部。在使用后，就变得很容易维护，而且数据流非常清晰，容易解决遇到的。 欢迎移步我的博客阅读：《React 入门实践》 在写这篇文章之前，我已经接触 React 有大半年了。在初步学习 React 之后就正式应用到项...
阅读 1897·2021-11-24 11:16
阅读 3259·2021-09-10 10:51
阅读 3184·2021-08-03 14:03
阅读 1262·2019-08-29 17:03
阅读 3239·2019-08-29 12:36
阅读 2223·2019-08-26 14:06
阅读 495·2019-08-23 16:32
阅读 2667·2019-08-23 13:42
