2014年八月，Codecademy为了更新用户的学习体验，决定采用Facebook的React.js库，这是一个用于编写JavaScript UI的类库。在开始阶段，我们的问题是很难找到React在复杂应用中应用的示例，例如像Codecademy这样复杂的应用。因为大多数的教程都是针对小型示例应用上的特性，而不是针对在开发大型应用中更常见的问题。在本文中，我不仅会对React的使用进行一番概述，还会特别说明在大型web应用程序中使用React的某些特别注意事项。React是什么？简单来说：React是一个使用JavaScript创建用户界面的代码库。与编写用户界面常见的方式不同，React将每个UI元素视为一个抑制的状态机。它并不是类似于AngularJS这样的“框架”。虽然Facebook有时会将React描述为“MVC中的V”，但我发觉这一描述并没有什么帮助，因为React应用并不需要遵守MVC模型。React能够帮助你创建快速的用户界面，处理复杂的交互，而无需编写大量糟糕的代码。如果你打算在工作中使用React，你需要了解以下特性：“React会为你处理DOM”DOM操作的开销很大，而React的吸引力很大程度上来自于它对这一问题的处理方式。React通过对自身虚拟DOM的维护，只在需要时进行重新渲染，将DOM操作的数量降至了最低，这要归功于React中高性能的比较操作的实现。这就意味着你很少会需要直接与DOM打交道，与之相反，React会替你处理DOM的操作。这一特性也是诸多React设计的基础。如果你打算滥用React的API，或是打算按照自己的方式进行改动，那有可能会影响到React对DOM的理解。该特性也使得使用Node.js进行内置的服务端渲染成为可能，这一点就使你能够轻易地创建对于SEO友好的页面。“React使用声明式风格以及组件”在React中，所有的组件都必须继承自Component类。组件中包含了属性（由父类决定）和状态（能够自行改变，通常是基于用户行为进行改变），组件的渲染和行为应当完全由它们的状态和属性所决定（而不依赖于任何其它值），因此组件就是状态机。这一模型鼓励使用者创建模块化的UI，并且在实践中能够简化UI的操作与创建工作。“React将标记紧密地结合在JavaScript中”虽然在JavaScript中编写HTML代码听起来很奇怪，但在React中这是一种自然的选择。JSX是原生的JS与HTML标记相结合的一种语言，对于它的使用是可选的，但我强烈建议你选择这种方式。React认为，由于你的标记已经紧密地结合在控制这些标记的JavaScript中，因此可以将它们安置在同一个文件中，我也同意这一看法。“单向信息流动”这一点更多的是一种通用的React模式，而不是一种严格的规则。信息的流动在React中倾向于单向流动。在本文的稍后部分中，当我们开始考虑在大型应用程序中如何处理信息流动时，会再次提及这一模式。解析React应用程序为了让这些原则显得更为清晰，让我们看看Codecademy的学习环境是如何使用React进行构建的。学习环境正如你在这个屏幕截图中所看到的一样，主要的学习环境由多个不同的UI元素所组成。某些元素是始终展现在页面上的，例如header、menu和navigation。而有些组件会根据当前的练习的不同，处于显示或是不显示的状态。比方如，根据课程的不同，web浏览器、命令行和代码编辑器可能会进行混合或是匹配。创建该界面的逻辑解决方案是为各个部分创建React组件。在下面的屏幕截图中，我将特别指出主要的React组件：学习环境以及对应的组件每个组件都有可能包含多个子组件：比方如，屏幕左方的Lesson面板实际上就包含了多个组件：组成Lesson组件的各个子组件在这个示例中，我们将使用React以决定哪些组件应该显示在该lesson面板中。举例来说：只有在用户已登录的前提下，才会显示“Report a Problem”按钮只有在该练习中包括测试的情况下，才会显示Instructions部分此外，React会处理该组件与其它组件之间的信息流动。整个学习环境对应着一个父组件，该组件会持续跟踪多个状态，例如当前用户处于哪个练习中。父组件会为子组件的属性进行相应的赋值，以决定这些子组件如何显示。现在，让我们来看一个组件通信的示例，以下组件来自经过大量简化后的组件树结构：LearningEnvironmentCodeEditorRunButtonErrorDisplayerNavigation与代码提交相关的某些组件如果某个用户打算运行他的代码，我们该如何处理这一工作流？我们将尝试对他们提交的代码进行测试，然后显示错误信息，或是允许用户继续下一题。以下是某个可能发生的工作流：当用户单击RunButton之后，该组件会在事件的调用中，通过回调方式通知它的父组件CodeEditor。CodeEditor组件会通过另一个回调函数通知它的父组件，即Learning Environment组件，并将用户的当前代码传递给父组件。LearningEnvironment组件将针对用户的代码进行测试。根据结果的不同……LearningEnvironment组件会对CodeEditor中的属性errorMessage赋值，CodeEditor则会依次为它的子组件ErrorDisplayer中的属性errorMessage赋值。如果用户已经完成了该练习的所有测试，LearningEnvironment组件就会为Navigation组件中的属性progress赋值。如果我们的组件都能够像在LearningEnvironment组件中的render方法一样进行声明（同样进行了大量简化），那么就可以通过一个单一的函数调用实现整个UI的更新：请记住，React中混合了JavaScript和HTML标记。在这个例子中，render方法定义了一个LearningEnvironment组件，其中包括了一个CodeEditor组件和一个Navigation组件。我们可以更新LearningEnvironment组件的状态，它会触发组件的重绘，并在必要时更新子组件。这就是全部的代码了。React以一种优雅而简单的方式替我们处理UI的更新操作。大型应用程序中的考虑因素：信息流动正如我之前所说的一样，React不一定要遵循MVC模型，实际上，你可以按照任何你喜欢的方式处理信息流动，但你需要一种确切的信息策略。为了让属性的变化传递给子-子-子-子-子组件，你是否需要将该属性一路传递下去，哪怕中间的那些子组件完全不需要了解该属性？如果该叶子节点接受用户输入，它又该如何将这一变更通知它的父-父-父-父组件呢？在大型应用程序中，这种处理方式是很令人受挫的。即使是在以上那个简单的示例中，Run按钮该如何与LearningEnvironment组件之间传递用户的行为呢？我们需要传递回调函数，但这种方式很难写出真正模块化、可重用的组件。Codecademy的解决方案是通过创建通信适配器（Adapter），以管理各别组件间的信息流动。与传递回调函数的方式不同，高层次的组件，例如CodeEditor会接收到一个Adapter，它为重要的通信任务提供了一种单一的接口。举例来说，当CodeEditor处于显示状态时，LearningEnvironment会创建一个Adapter，它能够生成和处理与用户提交代码相关的事件。这种方式也不是完全没有缺陷的，我也在React大会的演讲中针对这一点进行了详细的论述。我的主要观点在于，无论你如何处理组件树中的信息流动，你的团队都应该坚持一种一致的策略。大型应用程序中的考虑因素：整合React的上手非常简单，但要在你的工作流中高效地使用它，你需要一些工具的支持。举例来说，我们使用了以下工具：用一段脚本对.jsx文件的本地文化进行监控，并在必要时对它们进行重新编译一个独立的node.js服务器，用于处理服务端的展示用于在需要时自动生成新组件文件的开发者工具以上这些工具都不是非常复杂。对于.jsx的监控来说，Gulp是一个很好的选择，不过我们选择了使用Go语言自行编写脚本。我们使用了一个简单的批处理脚本负责生成新的组件文件，这种方式也能够确保命名规范。如果你打算使用一个node.js服务器以负责服务端展示，你需要当心的是，要强制require.js能够获取到React代码中的变更可能会有些困难，因此我们创建了一个监控器，让它在必要时重启node服务器。为什么使用React？在我们重新设计整个学习环境时，我们需要决定选择使用哪一套工具或框架。我们最终选择了React，对这一决定我们感到非常满意。我们对于React的欣赏之处主要在于以下几个方面：它经过了实战检验React已经在Facebook和Instagram的生产环境中得到应用，因此我们对于它的性能和可靠性很有信心。目前为止，它在我们的平台上同样表现良好，我们也没有遇到过任何严重的问题。组件化的方式便于理解React对每个独立的组件进行单独处理，这些组件会按照它内部的状态进行展现，因此对于某一时刻应该发生什么事，很容易形成概念化的理解。你的应用程序会有效地成为一个大型状态机。这意味着你可以单独测试UI中的每个片段，同样可以自由地添加新组件，而无需担心会影响整个应用程序中其它部分的代码。SEO非常容易实现因为React本身就支持服务端展现，因此在搜索引擎看来，你提供的是一个基本已完成的页面，这对于SEO来说是一个极大的优势，而所需的工作量非常小。的确，这一点必需由Node完成。由于Codecademy的主应用是由Rails编写的，因此我们搭建了一个独立的Node服务器，专门用于处理React的展现。React能够兼容遗留代码，并且它的灵活性足以应对未来虽然采用一整套框架的确是一件大事，但你也可以慢慢地尝试将React添加到现有的代码库中。与之类似，如果将来我们需要移除React，我们也可以轻易地实现这一点。在Codecademy，我们首先决定完全使用React来编写一个全新的项目，以便尝试它的功能，并学习如何以最佳的方式使用它。这个项目很成功，因此我们现在基本上在所有的新UI元素中都使用React了。我建议你首先做些功课，创建一些实验项目，然后再考虑怎样让React适应于你的现有代码库。不必担心编写样板代码了在编写样板代码上所花的时间越少，就意味着你可以将更多的时间花在更有意义的问题上了。从这个角度上来说，React是个既简洁又轻量级的类库。以下代码是创建一个新的组件所需的最少代码：简短且切题，还有什么不满意的？我们的社区正在成长React社区的发展非常迅速。当你遇到各种问题时，你可以和许多社区成员讨论这一问题。并且，由于许多公司都已经在生产环境中使用了React（仅举几例，Facebook、Instagram、Yahoo!、Github和Netflix），因此我们并不独孤。总结React是一个轻量级、强大，并且经过实战检验的使用JavaScript创建用户界面的类库。它不是一个框架，而是一个强大的工具，或许会改变你进行前端开发的方式。我们认为它对于我们的前端开发来说，作用之大是难以置信的，而我们对于自己的选择也感到相当满意。对我自己来说，使用React进行工作至少是极大地影响了我思考编写用户界面的方式。我也乐于看到React的不断成长：现在Facebook已经通过React Native将React的功能带到移动开发上了，我想它的未来一定会是一片光明。如果你打算上手使用React，它的教程是一个不错的逻辑起点。互联网上也有着大量介绍React中的关键概念的帖子。不要停下脚步，学习钻研，尝试着创建些什么，然后看看你对于React这种前端开发方式是怎么想的。我们非常乐于聆听你的想法。关于作者Bonnie Eisenman是一位来自于的软件工程师。她最近刚刚从普林斯顿大学的计算机科学专业毕业。她对硬件也有一定兴趣，在业余时间喜欢从事一些Arduino方面的工作，以及乐曲编辑。她的Twitter帐号是@brindelle。 【QCon北京2015】永不止步的前端专题，由蚂蚁金服体验技术部负责人王保平（玉伯）主持，重点讨论：移动 H5 应用的开发，包括 Web 与 Native 的融合；企业平台类富应用的开发，涵盖 Angular、React、Polymer 等技术方向；前端工程与质量体系的建设，关注团队的高效协同、品质把控；前端工程师的历史转身，何去何从。敬请期待。
看过本文的人还看过
人气：35869 更新：
人气：33440 更新：
人气：29597 更新：
人气：24756 更新：
InfoQ的更多文章
大家在看 ^+^
推荐阅读 ^o^
【新·知识】一起摇摆？NASA揭开地球千古谜题！
拿到苹果奖学金的天才少年，有这些你不知道的故事 | AppStory
京东证实收购一号店；裸贷女孩亲述经历：2千变6万逾期费吓死人； 马云说他最大的错误就是创建了阿里巴巴 | 早报
诺基亚，让你爱上新一代机神！
猜你喜欢 ^_^
24小时热门文章
微信扫一扫
分享到朋友圈react-native 之布局篇
招聘信息：
宽度单位和像素密度react的宽度不支持百分比，设置宽度时不需要带单位 {width: 10}， 那么10代表的具体宽度是多少呢？不知道是官网文档不全还是我眼瞎，反正是没找到，那做一个实验自己找吧：默认用的是iPhone6的模拟器结果是：我们知道iPhone系列的尺寸如下图：可以看到iphone 6的宽度为 375pt，对应了上边的375，由此可见react的单位为pt。 那如何获取实际的像素尺寸呢？ 这对图片的高清化很重要，如果我的图片大小为100*100 px. 设置宽度为100 * 100. 那在iphone上的尺寸就是模糊的。 这个时候需要的图像大小应该是 100 * pixelRatio的大小 。react 提供了flex的布局默认宽度我们知道一个div如果不设置宽度，默认的会占用100%的宽度， 为了验证100%这个问题， 做三个实验根节点上方一个View， 不设置宽度固定宽度的元素上设置一个View， 不设置宽度flex的元素上放一个View宽度， 不设置宽度结果可以看到flex的元素如果不设置宽度， 都会百分之百的占满父容器。水平垂直居中css 里边经常会做的事情是去讲一个文本或者图片水平垂直居中，如果使用过css 的flexbox当然知道使用alignItems 和 justifyContent . 那用react-native也来做一下实验网格布局网格布局实验， 网格布局能够满足绝大多数的日常开发需求，所以只要满足网格布局的spec，那么就可以证明react的flex布局能够满足正常开发需求等分的网格左边固定， 右边固定，中间flex的布局嵌套的网格通常网格不是一层的，布局容器都是一层套一层的， 所以必须验证在real world下面的网格布局好在没被我玩儿坏，可以看到上图的嵌套关系也是足够的复杂的，（我还加了一个ScrollView，然后再嵌套整个结构）嵌套多层的布局是没有问题的。图片布局首先我们得知道图片有一个stretchMode. 通过Image.resizeMode访问找出有哪些mode尝试使用这些mode100px 高度， 可以看到图片适应100高度和全屏宽度，背景居中适应未拉伸但是被截断也就是cover。contain 模式容器完全容纳图片，图片自适应宽高cover模式同100px高度模式stretch模式图片被拉伸适应屏幕随便试验了一下， 发现高度设置到父容器，图片flex的时候也会等同于cover模式绝对定位和相对定位和css的标准不同的是， 元素容器不用设置position：'absolute|relative' .相对定位的可以看到很容易的配合margin做到了。 （我还担心不能配合margin，所以测试了一下：-：）padding和margin我们知道在css中区分inline元素和block元素，既然react-native实现了一个超级小的css subset。那我们就来实验一下padding和margin在inline和非inline元素上的padding和margin的使用情况。padding在View上设置padding很顺利，没有任何问题， 但是如果在inline元素上设置padding， 发现会出现上面的错误， paddingTop和paddingBottom都被挤成marginBottom了。 按理说，不应该对Text做padding处理， 但是确实有这样的问题存在，所以可以将这个问题mark一下。margin我们知道，对于inline元素，设置margin-left和margin-right有效，top和bottom按理是不会生效的， 但是上图的结果可以看到，实际是生效了的。所以现在给我的感觉是Text元素更应该理解为一个不能设置padding的block。算了不要猜了， 我们看看也就是如果Text元素在Text里边，可以考虑为inline， 如果单独在View里边，那就是Block。&下面会专门研究一下文本相关的布局文本元素首先我们得考虑对于Text元素我们希望有哪些功能或者想验证哪些功能：文字是否能自动换行？overflow ellipse？是否能对部分文字设置样式 ，类似span等标签先看看文字有哪些支持的style属性实验1， 2， 3从结果来看1，2，3得到验证。 但是不知道各位有没有发现问题， 为什么底部空出了这么多空间， 没有设置高度啊。 我去除numberOfLines={5} 这行代码，效果如下：所以实际上， 那段空间是文本撑开的， 但是文本被numberOfLines={5} 截取了，但是剩余的空间还在。 我猜这应该是个bug。其实官方文档里边把numberOfLines={5}这句放到的是长文本的Text元素上的，也就是子Text上的。 实际结果是不生效。 这应该又是一个bug。Text元素的子Text元素的具体实现是怎样的， 感觉这货会有很多bug， 看官文Behind the scenes, this is going to be converted to a flat&NSAttributedString that contains the following information好吧， 那对于numberOfLines={5} 放在子Text元素上的那种bug倒是可以解释了。Text的样式继承实际上React-native里边是没有样式继承这种说法的， 但是对于Text元素里边的Text元素，上面的例子可以看出存在继承。 那既然有继承，问题就来了！到底是继承的最外层的Text的值呢，还是继承父亲Text的值呢？结果可见是直接继承父亲Text的。总结react 宽度基于pt为单位， 可以通过Dimensions 来获取宽高，PixelRatio 获取密度，如果想使用百分比，可以通过获取屏幕宽度手动计算。基于flex的布局view默认宽度为100%水平居中用alignItems, 垂直居中用justifyContent基于flex能够实现现有的网格系统需求，且网格能够各种嵌套无bug图片布局通过Image.resizeMode来适配图片布局，包括contain, cover, stretch默认不设置模式等于cover模式contain模式自适应宽高，给出高度值即可cover铺满容器，但是会做截取stretch铺满容器，拉伸定位定位相对于父元素，父元素不用设置position也行padding 设置在Text元素上的时候会存在bug。所有padding变成了marginBottom文本元素文字必须放在Text元素里边Text元素可以相互嵌套，且存在样式继承关系numberOfLines 需要放在最外层的Text元素上，且虽然截取了文字但是还是会占用空间
微信扫一扫
订阅每日移动开发及APP推广热点资讯公众号：CocoaChina
您还没有登录！请或
点击量3945点击量3765点击量3040点击量2737点击量2667点击量2593点击量2592点击量2521点击量2324
&2016 Chukong Technologies,Inc.
京公网安备89React Native如何做跨平台设计 - 博客频道 - CSDN.NET
yeana1的博客
也纳是一个海纳百川，包罗万象的平台。无论你是个人还是企业，平台都能满足你的需求。
分类：移动开发
React Native 的一大优势是：可以只用一种语法编写分别运行在 iOS 和 Android 平台上的程序，且可重用部分应用逻辑。
然而，与“一次编写，到处运行”的理念不同的是，React Native 的哲学是“一次学习，到处编写”。如此一来，即使用 React Native 编写不同平台的程序，也可以尽可能贴合每个平台的特性。
从 UI 的角度来看，每个平台都有自己独特的视觉风格、UI 范例甚或是技术层面的功能，那我们设计出一个统一的 UI 基础组件，然后再按照各平台特性进行调整岂不乐乎？
在后续的所有教程中，我们会仔细解读 App 的源代码，请克隆一份源代码到本地可访问的路径，然后根据配置说明在本地运行 App。在本章的教程中，你只需要阅读相关源代码。源代码地址：
/fbsamples/f8app
React Native 思维模式
在你写任何 React 代码之前，请认真思考这个至关重要的问题：如何才能尽可能多地重用代码？
React Native 的理念是针对每个平台分而治之，代码重用的做法看起来与之相违背，好像我们就应该为每个平台定制其专属的视觉组件一样，但实际上我们仍需努力让每个平台上的代码尽可能多地统一。
构建一套 React Native 应用视觉组件的关键点在于如何最好地实现平台抽象。开发人员和设计师可以列出应用中需要重用的组件，例如按钮、容器、列表行，头部等等，只有在必要的时候才单独为每个平台设计特定的组件。
当然，有一些组件相对于其它组件而言更为复杂，我们先一起来看看 F8 应用中不同的组件有什么区别。
请看 F8 应用的示例图：
在 iOS 版本中，我们用 iOS 系统中很常见的圆角边框风格来切分 Tab 控制；在 Android 版本中，我们用下划线的风格来标示这个组件。而这两个控制组件的功能其实完全相同。
所以，即使两者样式稍有不同，但是实现的功能相同，所以我们可以用同一套代码抽象此处的逻辑，从而可以尽可能多地重用代码。
我们针对像这样的小组件做了很多跨平台重用逻辑代码的案例，比如一个简单的文本按钮，在每个平台上我们都会设计不同的 hover 和 active 状态的样式，但是除开这些视觉上的细微的差异外，逻辑功能完全相同。所以我们总结了一个抽象 React Native 视觉组件的最佳实践方法：设计一套相同的逻辑代码，然后在控制语句中编写其余需要差异化的部分。
以下是这个组件的示例代码：
在这段代码中，我们为每一种平台分别应用了不同的样式（用到了 React Native 的
&Platform 模块）。各平台中的 Tab 按钮都应用了相同的通用样式，同时也根据各平台特性定制了独占样式：
在这段代码中我们使用了一个改编自&React Native StyleSheet API的函数 F8StyleSheet，它可以针对各平台分别进行样式转换操作：
在这个&F8StyleSheet&函数中我们解析了前面示例代码中的&styles&对象，如果我们发现了匹配当前平台的&ios&或&android键值，就会应用相应的样式，如果都没有，则应用默认样式。以此看来，减少代码重复的另一种做法是：尽可能多地重用通用样式代码。
现在，我们已经可以在我们的App中重用这个组件了，它也可以根据不同的平台自动匹配相应的样式。
分离复杂差异
如果一个组件在各平台上的差异不仅仅是样式的不同，也存在大量的逻辑代码差异，那我们就需要换一种方式了。正如下图所示，iOS 和 Android 平台中最高阶的菜单导航组件就有非常大的差异：
正如你所见，在 iOS 版本中我们在屏幕底部放了一个固定的 Tab，而在 Android 版本中，我们却实现了一种可划出的侧边栏。这两种组件其实是本质上的不同，况且一般来说，在 Android 应用中，这种侧边栏通常还会包含更多的菜单选项，例如：退出登录。
你当然可以将这两种菜单模式写到一个组件中去，但是这个组件会变得异常臃肿，所有的差异不得不通过大量的分支语句来实现，你一定会在不久的将来对这段代码感到陌生难懂。
其实，我们可以用 React Native 内建的平台特定的扩展来解决这个问题。我们可以创建两个独立的应用，在下面的示例中我们会创建两个组件，分别命名为：F8TabsView.ios.js&和&F8TabsView.android.js。React Native 会自动检测当前平台并根据扩展命名加载相应的组件。
内建UI组件
在每一个&FBTabsView&组件中，我们也可以重用一些内建的 React Native UI 组件，Android 版本使用的是DrawerLayoutAndroid（很显然，只在 Android 中可用）：
在第8行代码中，我们在当前的类中显式地为 drawer 组件指定了&renderNavigationView()&函数。这个函数会返回 drawer 中渲染出来的内容。在这个示例中，我们渲染的是一个包含在自定义&MenuItem&组件中的&ScrollView
相比之下，iOS 版本直接在&render()&函数中使用了一个不同的内建组件，TabBarIOS：
显而易见，尽管 iOS 菜单接受了相同的数据，但是它的结构略有不同。我们并没有用一个独立的函数创建菜单元素，而是将这些元素作为父级菜单的子元素插入进来，正如&TabBarItemIOS组件一样。 这里的&TabBarItem&与 Android 中 的&MenuItem&本质上是相同的，唯一的区别是在
Android 组件中我们会定义一个独立的主View 组件：
&style={styles.content}
&key={this.props.activeTab}&
&{this.renderContent()}
然后当一个 tab 改变时改变这个组件（通过&renderContent()&函数），而 iOS 组件则会有多个分离的&View&组件，例如：
&GeneralScheduleView
&navigator={this.props.navigator}
&onDayChange={this.handleDayChange}
这是&TabBarItem&的一部分，可以点击使它们可见。
设计迭代周期
当你构建任何应用，无论是在移动平台还是 web 环境下，调整适配的 UI 元素是非常痛苦的。如果工程师和设计师共同协作，会使整个过程慢下来。
React Native 包含了一个实时重载的 debug 功能，可以当 JavaScript 改变时触发刷新应用。这可以在极大程度上减少设计迭代过程，一旦改变了组件样式并保存后，你会立即看到更新的样式。
但是如果组件在不同条件下看起来不同怎么办呢？举个例子，一个按钮组件可能有一个默认样式，也分别包含按下、执行任务中、执行任务完成时的样式。
为了避免每次都与应用交互，我们内建了一个用于 debug 视觉效果的&Playgroud&组件：
其实我们只是创建了一个可交换加载的空视图，将其与一些示例定义整合到其中一个 UI 组件中，正如下面这段AddToScheduleButton.js&所示：
我们可以将这个应用转化为一个 UI 预览工具：
在这个示例中为这个按钮定义了按下和抬起两种状态，第三个按钮在这两者的状态之间不断循环，以此来预览过渡的动画效果。
现在，我们可以跟设计师一起快速调整基础组件的视觉样式了。
如果想用这个功能，&Playground&&组件必须在任何 React Native 应用中都可用，我们需要在&setup()&函数中交换一些代码来加载&&Playground&&组件：
/* from js/setup.js */
render() { &
& &&Provider store={this.state.store}&
& & &&F8App /&
& &&/Provider&
/* in js/setup.js */
render() {
& &&Provider store={this.state.store}&
& & &&Playground /&
& &&/Provider&
当然，你也可以修改&&Playground&&组件，使其能够改变引入的其它组件。
排名：千里之外
（11）（54）（11）