之前翻译了两篇关于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星散出来，便于今后举行复用
然则才用两天，就晓得这么搞有何等坑了。容器组件模子的目标就是复用性，可读性，可保护性，然则虽然我们很胜利的把背景交互和页面展现星散开了，然则看到这么多代码放在一同，我没有以为到任何复用性，可读性，可保护性，那末多代码，而且都夹杂了营业逻辑，你让我怎样复用，明白，保护？！
Round 2:
痛定思痛，决议改一下，针对之前的题目，面向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 4
View-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来。
假如这篇文章指点的方向有毛病，内里有许多的题目，该怎样办？
迎接指出和议论，统统题目都邑仔细回复，虚心接受。
假如我也答不出来，那我会看成没看到…
