本文共 30354 字，大约阅读时间需要 101 分钟。
react vs 2017
by Nicolas Cuillery
由Nicolas Cuillery
Few days ago, the 3rd edition of the biggest React conference in Europe took place in Paris. No heatwave or transportation strike this year — only great talks and interesting people.
几天前，欧洲最大的React会议的第三版在巴黎举行。 今年没有热浪或交通罢工-只有精彩的演讲和有趣的人。
Here is my feedback from my most appreciated talks of this edition.
这是我对此版最受赞赏的演讲的反馈。
Speaking of interesting people, I’d like to warmly thank Tchen Pan, just met among the audience, for his review of this article, as well as my team mates at .
谈到有趣的人，我要热烈感谢刚在观众中遇到的 Tchen Pan，感谢他对本文的评论，以及我在队友。
Those who came especially to hear news and updates about React could be satisfied: opened the conference with the roadmap for React. All these updates can be resumed in a single name: React Fiber.
那些特别想听到有关React的新闻和更新的人可能会感到满意： 在会议上发布了React的路线图。 所有这些更新都可以使用一个名称恢复：React Fiber。
Andrew illustrated React Fiber with a performance analysis of the video streaming in the newsfeed. They had to deal with poor performance caused by other tasks blocking the main JS thread. It was a scheduling problem, solved by splitting the execution of the tasks: the main thread is able to process chunks as they arrive so videos are no longer interrupted. The idea behind React Fiber is to schedule these tasks at the component level via the async rendering.
安德鲁(Andrew)通过对新闻源中视频流的性能分析说明了React Fiber。 他们必须处理由于其他任务阻塞主JS线程而导致的性能下降。 这是一个调度问题，通过拆分任务的执行来解决：主线程能够在块到达时对其进行处理，因此视频不再被中断。 React Fiber背后的想法是通过异步渲染在组件级别安排这些任务。
Coming in React 16, the revamp will also include fragments (group of sibling component, no more div wrapper, just return an array in the render function). Also a better error handling will be shipped with error boundaries (i.e. try/catch for component) and distinction of critical errors from the others. In case of critical error, the component will unmount to avoid degraded UI, corrupted datas…
在React 16中，修订版还将包括片段(同级组件组，不再有div包装器，只需在render函数中返回一个数组)。 同样，更好的错误处理将附带错误边界(即组件的try / catch)以及将关键错误与其他错误区分开来。 如果发生严重错误，将卸载该组件以避免UI降级，数据损坏……
React 16 is already in production, ready to install with the next tag:
React 16已经投入生产，可以使用下一个标签安装：
yarn add react@next
yarn add react@next
Beyond React 16, the enhanced render scheduling allows rendering to be prioritized, depending on the viewport position: this allows offscreen or hidden elements to render last without delaying rendering of “immediately-visible” components. It could also improve the user experience when using code-splitting within the current screen. Code-splitting could cause a smoothless cascading rendering of the screen. To avoid this side-effect, React 16 introduces a “commit phase” which consists to delay all the DOM updates at the end of the rendering phase to avoid inconsistent DOM.
除了React 16之外，增强的渲染计划还允许根据视口位置对渲染进行优先排序：这允许屏幕外或隐藏的元素最后渲染而不会延迟“立即可见”组件的渲染。 在当前屏幕中使用代码拆分时，它还可以改善用户体验。 代码拆分可能导致屏幕的级联渲染不流畅。 为了避免这种副作用，React 16引入了一个“提交阶段”，该阶段包括在渲染阶段结束时延迟所有DOM更新，以避免DOM不一致。
Introducing React Fiber was a great way to open the conference. Its new features are highly anticipated by the community. To learn more about React Fiber:
介绍React Fiber是打开会议的好方法。 它的新功能受到社区的高度期待。 要了解有关React Fiber的更多信息，请访问： :
from Facebook presented the recent optimizations on the React package. Inspired by the design of lightweight clones of React like Inferno (created by him) & Preact, he works to make the React package lighter and faster to load.
来自Facebook的展示了React软件包的最新优化。 受诸如Inferno(由他创建)和Preact之类的React轻量级克隆设计的启发，他致力于使React包更轻，更快地加载。
Thanks to a new build system backed by , the React package gains 10% weight and is 9% faster to load.
多亏了支持的新构建系统，React程序包的重量增加了10％，加载速度提高了9％。
Webpack is for apps, Rollup is for libraries
Webpack适用于应用程序，汇总适用于库
They also externalize the PropTypes support as well as deprecated code like React.createClass (see ).
它们还外部化了PropTypes支持以及诸如React.createClass类的已弃用代码(请参阅 )。
Dominic pointed out the importance of using a powerful and consistent benchmark tool when trying to optimize the React package. He showed an interesting “snapshot benchmarking” tool comparing current metrics versus the previous one (package size, initial load time, time to interactive) that runs on .
Dominic指出了在尝试优化React软件包时使用功能强大且一致的基准测试工具的重要性。 他展示了一个有趣的“快照基准测试”工具，该工具将当前指标与运行在上的指标(程序包大小，初始加载时间，互动时间)进行了比较。
This tool was a great help to get confidence when moving the React codebase. It is a prerequisite to make React smaller and faster.
这个工具在移动React代码库时很有帮助。 使React变得更小，更快是一个先决条件。
To know more about Dominic’s work:New build system: Benchmark:
要了解有关Dominic的工作的更多信息：新建系统： : 基准测试： :
As an early adopter of Jest, I can tell that using Jest two years ago was like crossing the desert. I also lived the mutation of Jest which is nowadays a great and widely-used tool. That’s why I was very pleased to hear telling that story.
作为Jest的早期采用者，我可以说两年前使用Jest就像穿越沙漠。 我还经历了Jest的变种，Jest的变种如今已成为一种广泛使用的出色工具。 这就是为什么我很高兴听到讲这个故事的原因。
That story is: how Jest has turned from a tool into a “product”. A product is focused on performance and features which bring adoptability, and in case of a test runner, 2 experiences must be delightful: running tests and writing tests.
那个故事是：Jest是如何从工具变成“产品”的。 产品侧重于带来可采用性的性能和功能，如果是测试跑步者，则必须有2种经验：运行测试和编写测试。
The performance has been improved by implementing parallel test runs, using all the CPUs, and measuring the execution times to schedule them better for the next runs.
通过使用所有CPU实施并行测试运行并测量执行时间以更好地调度它们以进行下一次运行，可以提高性能。
Christoph and the community made a great job to bring interesting features into Jest, like relevant output (useful diff instead of pointless error stacktrace), immersive watchmode (interactive CLI, navigation among the list of test cases to rerun them).
Christoph和社区在将有趣的功能引入Jest方面做得很出色，例如相关的输出(有用的diff而不是无意义的错误堆栈跟踪)，沉浸式监视模式(交互式CLI，在测试用例列表中导航以重新运行它们)。
Christoph mentioned the snapshot testing: in addition to conventional testing (it’s not a replacement !), it’s a great way to visualize the comprehensive output of a component (current vs expected).
Christoph提到了快照测试：除了常规测试(这不是替代品！)之外，它还是一种可视化组件的全面输出(当前与预期)的好方法。
Jest 20 will come with the multi-project runner. By using the option --projects Jest is able to run multiple test suites and consolidate tests result in a single terminal window. Useful for using the watch-mode on a multi-repo codebase.
Jest 20将与多项目运行器一起提供。 通过使用--projects选项，Jest能够运行多个测试套件并将测试结果合并到一个终端窗口中。 在多仓库代码库上使用监视模式时很有用。
Jest has been moved to a multi-package architecture and some of them are used on several projects at Facebook: jest-haste-map, jest-snapshot, jest-validate (an CLI options parser like ). It has been useful internally to consolidate their infrastructures and share best practices.
Jest已移至多包体系结构，其中一些已在Facebook的多个项目中使用：jest-haste-map，jest-snapshot，jest-validate(CLI选项解析器，如 )。 在内部对巩固其基础架构和共享最佳实践很有用。
Worth to mention: Jest is now maintained by 2 core developers + the community. We are strongly encouraged to contribute, Jest project is approchable and easy to contribute.
值得一提：Jest现在由2位核心开发人员+社区维护。 我们强烈建议您做出贡献，Jest项目是可申请的且容易做出贡献。
Blog post about Jest 20:
关于Jest 20的博客文章： :
The point of this talk is that the JavaScript fatigue is a good thing, healthy for the ecosystem. started by remind us what the is.
这次演讲的重点是，JavaScript疲劳是一件好事，对生态系统而言是健康的。 首先提醒我们是什么。
Hundreds of new librairies are announced each month on . It’s impossible to take a look to everything. The good news is that you don’t have to: just pick the right thing.
每个月都会在上宣布数百项新 。 看所有东西是不可能的。 好消息是您不必：只需选择正确的东西 。
From a principle conceived by Richard P. Gabriel in the eighties, the right thing has 4 golden characteristics:
从八十年代理查德·加布里埃尔(Richard P. Gabriel)构想的原理出发，正确的事情具有四个黄金特征：
But history shows that the right thing is sometimes… not the right thing. Actually, only the simplicity matters.
但是历史表明，有时候正确的事情……不是正确的事情。 实际上，只有简单性才重要。
Simple things are easier to integrate.
简单的事情更易于集成。
The concept of worse is better is born. We could bear a lack of correctness, consistency or completeness if the thing is simple to handle!
更好的概念诞生了。 如果事情很容易处理，我们可能会缺乏正确性，一致性或完整性！
At this point came the parallel with the raise of React: Simplicity above all other characteristics.
在这一点上，React：简单性超越了所有其他特征。
Simplicity leads to popularity which leads to contributors. Today we can enjoy all that React was missing at its launch : state management, routing, getting started tools (create-react-app).
简单导致受欢迎，从而导致贡献者。 今天，我们可以享受React在启动时所缺少的一切：状态管理，路由，入门工具(create-react-app)。
Speaking of create-react-app, it really gathers all the best things brought by the community since 3 years and it is far better that it could have been at React launch.
说到create-react-app，它确实收集了3年以来社区带来的所有最好的东西，而且它本来应该是在React发行时更好的。
The JavaScript fatigue, then, is simply the consequence of the huge number of open-source contributors.
那么，JavaScript的疲劳仅仅是由于大量开源贡献者的结果。
In conclusion, launch something simple, make it popular (documented, battle-tested), then fill the holes.
总之，发布一些简单的东西，使其流行起来(有文件证明，经过战斗测试)，然后填补漏洞。
I found Kevin has made an interesting analogy between the modern JavaScript ecosystem and the worse is better vs the right thing theory.
我发现Kevin在现代JavaScript生态系统之间做了一个有趣的类比， 与正确的理论相比， 更糟的是更好 。
Excellent article about the Richard P. Gabriel theory:
关于Richard P. Gabriel理论的出色文章： ：
This Japanese word designates the art of “beauty into imperfection”. made a philosophic and very inspirational talk () about trade-offs.
这个日语单词表示“美到不完美”的艺术。 就权衡问题进行了富有哲理和启发性的演讲( )。
Trade-offs are a big part of our job as software engineer because we don’t have unlimited time and money. So we use pieces of software which imperfectly covers our needs. Let’s say 80% of our needs: it corresponds to the sweet spot on the Pareto curve, a.k.a. the 80/20 rule. It means that a reasonable amount of time (about 20%) is sufficient to cover 80% of our needs.
权衡是我们作为软件工程师的工作的重要组成部分，因为我们没有无限的时间和金钱。 因此，我们使用的软件不能完全满足我们的需求。 假设我们有80％的需求：它对应于帕累托曲线上的最佳点 ，也就是80/20规则。 这意味着合理的时间(约20％)足以满足我们80％的需求。
Our IT world is full of 80% systems. For example, image compression: if you get 80% of the original image for 20% of its size, that’s a good trade-off.
我们的IT世界充满了80％的系统。 例如，图像压缩：如果以原始图像尺寸的20％获得原始图像的80％，那是一个很好的权衡。
About React, the trade-off may be the communication with sibling components which is far harder than parent/child components… The cause is the tree model, convenient for 80% of the case. The 100% approach would be a graph model.
关于React，折衷方案可能是与兄弟组件进行通信，而兄弟组件比父/子组件难得多……原因是树模型，在80％的情况下都很方便。 100％的方法将是图形模型。
Flux is a 80% system too. Some tasks are difficult, like managing side-effects or external sources of changes. Redux is generally great but the unlucky programmers in the 20% area need dirty workarounds. It reminds me the for example.
助焊剂也是80％的系统。 有些任务很困难，例如管理副作用或外部变更源。 Redux通常很棒，但是20％的领域中不幸的程序员需要肮脏的解决方法。 例如，它使我想起了 。
Some things are not meant to be optimized.
有些事情并没有被优化。
It’s important to point out that, sometime, the trade-off is intentional because we are in the sweet spot, we don’t want to move. Let’s come back to the React example above, if React moved to a graph model handling 100% of the use cases, the whole library would be more complex which is not a good thing.
重要的是要指出，有时是有意进行权衡的，因为我们处在最佳状态，我们不想移动。 让我们回到上面的React示例，如果React移到一个处理100％用例的图形模型，那么整个库将变得更加复杂，这不是一件好事。
Being in a 80% system give us wiggle room, it boosts our creativity and adaptability. I work for few months with which I can now describe as “a trade-off for the 20% of the cases Redux doesn’t cover”.
处于80％的系统中会给我们摆动的空间，这会增强我们的创造力和适应性。 我在工作了几个月，现在可以形容为“在Redux无法覆盖的20％情况下进行权衡”。
There are disadvantages in the 80% approach. First of all: the 20% obviously. it may not be chosen to build foundations. Moreover, the 80% design generally makes composing a nightmare (mutations, side-effects, …).
80％的方法有缺点。 首先：显然是20％。 它可能不会被选择来建立基础。 而且，80％的设计通常会使作梦成为噩梦(变异，副作用等)。
Some stuff belong to the 100% world. For example, types checking with Flow: a great strength of Flow is the ability to incrementally typing your code base. It’s okay to add Flow file by file but you can’t add Flow partially within a file because you wouldn’t be able to say “Ok, this part of my app is strongly type-checked, I trust it”. You would loose the benefit of the type-checking (the confidence).
有些东西属于100％的世界。 例如，使用Flow进行类型检查：Flow的一项强大功能就是能够增量键入代码库。 可以逐个文件添加Flow文件，但是您不能在文件中部分添加Flow，因为您不能说“好吧，我的应用程序的这一部分经过了严格的类型检查，我相信它”。 您会失去类型检查(置信度)的好处。
It’s interesting to mention that 80% and 100% systems can be complementary: you can use a 80% tool because you have a compiler behind the scene (100%, the compiler never bails on you).
有趣的是，80％和100％的系统可以互补：您可以使用80％的工具，因为您在后台有编译器(100％的编译器永远不会失败)。
Reading documentation is a 80% action, reading source code is 100%.
阅读文档是80％的操作，阅读源代码是100％。
In conclusion, Cheng mentioned a publication of Leslie Lamport as a source of inspiration for his talk. He says that the credibility of the 80% approach varies with the domain of science, from 0% in Math to 100% in sociology/psychology.
最后，Cheng提到Leslie Lamport的出版物是他演讲的灵感之源。 他说，80％方法的可信度随科学领域的不同而不同，从数学的0％到社会学/心理学的100％。
Again, Cheng has the awesome skill to look at the bigger picture with hindsight. I found his talk very instructive and… kind of refreshing in such a technical conference.
再一次，Cheng拥有超凡的技巧，事后看来。 我发现他的演讲很有启发性，并且……在这样的技术会议上令人耳目一新。
Leslie Lamport’s publication:
莱斯利·兰伯特(Leslie Lamport)的出版物： :
introduced his talk with some metrics about the initial render time (+1s page load time on a commercial website leads to -20% conversion rate), making the point that SSR (Server Side Rendering) is vital.
在演讲中介绍了一些有关初始渲染时间(在商业网站上+1秒的页面加载时间导致-20％的转化率)的指标，这表明SSR(服务器端渲染)至关重要。
But SSR comes with an other problem: It causes a delay between the first render (the browser paints the server-side-rendered markup immediately) and the “time-to-interactive” (the browser has loaded the bundle and the SPA is on). This duration is called in a funny way by the “uncanny valley”.
但是SSR还存在另一个问题：它导致第一次渲染(浏览器立即绘制服务器端渲染的标记)与“交互时间”(浏览器已加载包并且SPA处于打开状态)之间存在延迟。 )。 ( 以滑稽的方式将这段时间称为“不可思议的山谷”。
Moreover, the SSR doesn’t scale well: the more your page is complex, the more it takes to render on the server-side. And it’s difficult to tell to your PO: “No, no, no, I can’t do that, it will make the whole page slower !”
而且，SSR不能很好地扩展：页面越复杂，在服务器端呈现的时间就越多。 而且很难告诉您的采购订单：“不，不，不，我不能这样做，这会使整个页面变慢！”
Multiples things happen when a page is rendered on the server-side:
在服务器端呈现页面时，会发生多种情况：
The problem is that all these tasks happen sequentially. What if we can parallelize things ?
问题在于所有这些任务都是顺序发生的。 如果我们可以并行化事情怎么办？
Instead of a huge monolithic SSR, the server could process the render of the page fragment by fragment. Let’s consider a page made of a title, a main content and comments for example, Sasha showed that the server could returns a “chunk”, i.e. all pieces necessary to render a portion of the page (HTML + CSS + JS + JSON) for each part of the page.
服务器可以代替庞大的整体SSR，而是逐个片段地处理页面片段的呈现。 让我们考虑一个由标题，主要内容和注释组成的页面，例如，Sasha显示服务器可以返回“块”，即，呈现页面的一部分(HTML + CSS + JS + JSON)所需的所有内容页面的每个部分。
With this approach (SCR or Server Chunk Rendering), both initial render time and uncanny valley duration are reduced (especially on mobile) because the SSR is more of a “stream” now, it could be parallelized:
使用这种方法(SCR或服务器块渲染)，可以减少初始渲染时间和异常谷值持续时间(尤其是在移动设备上)，因为SSR现在更像是“流”，因此可以并行处理：
An other benefit is: if one of the multiple calls to the API falls into a black hole, it doesn’t take the whole page down, but only the area concerned by the chunk.
另一个好处是：如果对API的多次调用之一陷入了黑洞，那么它不会使整个页面都掉下来，而只会占用该块所涉及的区域。
I had a lot of interrogation in mind after the talk: how to define the chunks within each page of the app ? does it imply the return of the good old HTML templates ? (I guess I have to take a look at Sasha’s lib ), but, yes, it seems we had a glimpse of what the future of the SSR will be:
演讲之后，我想到了很多疑问：如何在应用程序的每个页面中定义块？ 这是否意味着好的旧HTML模板会返回？ (我想我必须看一下Sasha的lib )，但是，是的，看来我们对SSR的未来将会有所了解：
Rename ReactServer -> ReactDOMServerStream This file is going to be the replacement for ReactDOMServer.
重命名ReactServer-> ReactDOMServerStream此文件将替代ReactDOMServer。
Recent pull requests show that something is coming in the official React repo:
最近的请求显示官方React回购中出现了一些问题： :
Blog post about the uncanny valley:
有关不可思议的山谷的博客文章： :
spoke about “renderless” components. Those components don’t render anything but enjoy the React lifecycle though.
谈到了“无渲染”组件。 这些组件除了呈现React生命周期外，什么都不会呈现。
He presented a dead simple Log component which prints its child in the console, every time it changes, thanks to the React lifecycle.
他展示了一个简陋的简单Log组件，由于React生命周期的缘故，每次更改时，该组件都会在控制台中打印其子级。
Then, a more serious example: a component wrapping the that read out loud the content of a text input. The component is able to interrupt the current speech before reading the new content: since the new content is a prop, that could be easily implemented in a componentWillReceiveProps.
然后是一个更严重的示例：包装的组件，该组件可大声读出文本输入的内容。 该组件能够在读取新内容之前中断当前语音：由于新内容是道具，因此可以在componentWillReceiveProps轻松实现。
Joshua has gathered great explanations (as well as slides and examples) in his Github repository:
Joshua在他的Github存储库中收集了很棒的解释(以及幻灯片和示例)： :
Even people who have never heard about Detox knew that something was coming when the audience applauded before the talk began, just when the title appeared on the screens!
即使是从未听说过Detox的人，也知道在演讲开始前听众鼓掌的时候(即将在标题出现在屏幕上时)有些事情发生了！
In the mobile development world, manual QA is time consuming, up to 10 full days for the Wix app. So and people at Wix put effort in automated tests and used the number 1 framework: . It didn’t give satisfaction because tests have to run on real devices, they are very slow, complicated to write and flaky (they end up with sleep() everywhere). So they decided to create a new tool: Detox!
在移动开发世界中，手动质量检查非常耗时，对于Wix应用程序最多需要10天的时间。 因此和Wix的工作人员致力于自动化测试，并使用了排名第一的框架： 。 由于测试必须在真实的设备上运行，所以测试结果不令人满意，它们非常慢，编写复杂且不稳定(它们到处都带有sleep() )。 因此，他们决定创建一个新工具：排毒！
While Appium is a blackbox, Detox is more of a “greybox”: everything on the device (or simulator) is monitored (network, JS thread, etc.), kept controlled and synchronized to avoid flakiness.
尽管Appium是一个黑匣子，但Detox却更像是一个“灰匣子”：设备(或模拟器)上的所有内容(网络，JS线程等)均受到监控，并保持受控和同步以避免松散。
The talk ended up with a video showing a very fast test suite execution.
演讲的最后是一个视频，显示了非常快速的测试套件执行。
We encountered the exact same problems with Appium in my client company . Due to the lightning talk format, it was impossible to explain in detail the internal of Detox so we still have a lot of questions (does it work with brownfield app ?), but we’ll definitely try Detox by ourselves!
我在客户公司遇到了与Appium完全相同的问题。 由于闪电般的交流方式，无法详细解释Detox的内部，所以我们仍然有很多问题(它是否适用于brownfield应用程序？)，但我们肯定会自己尝试Detox！
Repo:
回购： :
Great way to close Day 1: a visual lightning talk full of cool stuff like video games, image filters, data viz, ... by from Expo.
结束第一天的好方法：一场视觉闪电般的谈话，充满了很酷的东西，例如视频游戏，图像过滤器，数据可视化……来自Expo的 。
James presented the GLView component of Expo which is able to display OpenGL GPU-accelerated graphics on a mobile device.
James展示了Expo的GLView组件，该组件能够在移动设备上显示OpenGL GPU加速的图形。
GLView component architecture is a bit different from other React Native component. It used the ability of JavaScriptCore (the mobile JavaScript execution environment) to call the C native API without using the main bridge. So the graphics are not affected by the occupation on the bridge.
GLView组件架构与其他React Native组件略有不同。 它使用JavaScriptCore(移动JavaScript执行环境)的功能来调用C本机API，而无需使用主桥。 因此，图形不受桥上占用的影响。
Then James showed some graphic interfaces like effects on the video stream from the camera, video-games and an example of a 3D view created with the existing library that is compatible with React Native.
然后，詹姆斯展示了一些图形界面，例如对摄像机视频流的效果，视频游戏以及使用与React Native兼容的现有库创建的3D视图示例。
GLView documentation:
GLView文档： :
I found that Functional Programming is generally incredibly useful, concise and elegant, but we shouldn’t fall in the trap of doing FP… for doing FP, when code becomes less readable and understandable than before. didn’t fall in that trap when he presented his talk about composition, inspired by his work on the color API of .
我发现函数式编程通常非常有用，简洁和优雅，但是当代码变得比以前更易读和理解时，我们不应该陷入执行FP的陷阱……做FP。 在演讲关于构图的时候并没有陷入这个陷阱，灵感来自他对色彩API的研究。
To illustrate the original problem, Nik presented an example of imperative code using (since the live video has been temporary removed from YouTube, I’ve rewritten similar code snippets):
为了说明原始问题，Nik展示了一个使用的命令式代码 (由于实况视频已从YouTube中临时删除，因此我重写了类似的代码段)：
That code full of temporary variables could be improved with the chain API:
可以使用链API改进充满临时变量的代码：
That is more concise but still not perfect, there are still the chain and value operator (seriously, who have never forgotten .value() at the end of an explicit Lodash chain?). Moreover, the chain API kills the ability to partially import Lodash (see ).
这更加简洁，但仍不完美，仍然有chain和value运算符(严重的是，他们在明确的Lodash链的末尾没有忘记.value()吗？)。 而且，链式API杀死了部分导入Lodash的能力(请参阅 )。
Real composition allows to define a pipe with , :
实际组合物允许定义与管道 ， ：
We can find a similar ugly syntax in React with the HoC (High-Order Component) pattern and, again, composition could improve the readability:
我们可以在React中使用HoC(高阶组件)模式找到类似的丑陋语法，并且再次编写可以提高可读性：
The compose function from either Ramda, lodash/fp, recompose or react-apollo can be used here (oh, I’ve already put the mind-blown gif in this article, right ?). So it seems there is a real pattern here.
可以在此处使用Ramda，lodash / fp，recompose或react-apollo的compose函数(哦，我已经在本文中添加了让人难以置信的gif，对吗？)。 因此，这里似乎有一个真实的模式。
That was a source of inspiration when Nik created the color API of polish: a color could be a composition of tint, light and saturation! They made a cool api like Ramda or Lodash/fp, composable but also usable in the imperative style thanks to currying.
当Nik创建波兰语的颜色API时，这就是灵感的来源：颜色可能是色调，光和饱和度的组合！ 他们制作了很酷的api，例如Ramda或Lodash / fp，它可组合，但由于使用了curring，也可以按命令式使用。
Back to React, Nik showed that we can write our own HoC function to avoid repetition. For example, when we have a bunch of component that need a boolean prop to be true to display content:
回到React，Nik展示了我们可以编写自己的HoC函数来避免重复。 例如，当我们有一堆需要布尔属性为真才能显示内容的组件时：
We can do the same with a HoC function withErrorMessage that decorate a text input with an error message for example.
我们可以使用带有ErrorMessage的HoC函数( withErrorMessage ，用错误消息修饰文本输入)来执行相同的操作。
Nik closed the talk with a React VR screen showing planets rotation, the rotation is implemented with a syntax similar to React Native Animated. He explains how the animation is contained in a reusable HoC function withRotation.
Nik通过一个显示行星自转的React VR屏幕结束了对话，自转采用类似于React Native Animated的语法实现。 他解释说动画是如何包含在可重复使用的特殊功能withRotation 。
This talk provided relevant examples to illustrate FP concepts like currying, Higher-order-Function and how they could be applied to React (Higher-order-Component). I’m definitely looking forward to analyze the withRotation HoC and see if I could transpose that on my React Native projects.
该演讲提供了相关示例来说明FP概念，例如currying，Higher-order-Function及其如何应用于React(Higher-Order-Component)。 我绝对期待分析withRotation HoC，看看是否可以在我的React Native项目中进行转置。
React doc about composition & HoC:
React有关成分和HoC的文档： ://facebook.github.io/react/docs/higher-order-components.html
It’s a well-known fact that Airbnb makes an extensive use of React and React Native. pointed out that it was a big step forward:
众所周知，Airbnb广泛使用了React和React Native。 指出这是向前迈出的一大步：
Instead of writing Airbnb 3 times (for Web, iOS and Android) by 3 different teams (JavaScript / Java / Swift), React and React Native allows a 2-time writing (Web and native) by the same team (Javascript). But now, the engineer writes twice the almost identical code. Couldn’t it be better if they write it only once ?
React和React Native不需要由3个不同的团队(JavaScript / Java / Swift)编写3次(对于Web，iOS和Android)(针对Web，iOS和Android)，而是由同一团队(Javascript)进行2次写作(Web和Native)。 但是现在，工程师编写了几乎相同代码的两倍。 如果他们只写一次会更好吗？
Write one, run anywhere ?
写一个，在任何地方运行？
Leland thinks we can achieve that. React Native was an eye-opener: React can address multiple platforms. Then, had come, followed by Windows, Ubuntu, VR, …
Leland认为我们可以实现这一目标。 React Native令人大开眼界：React可以处理多个平台。 然后， 出现了，随后是Windows，Ubuntu，VR等……
The biggest obstacle of component sharing between platforms is the import of the platform implementation, for example with React Native:
平台之间组件共享的最大障碍是平台实现的导入，例如使用React Native：
import { View } from 'react-native'; Note that a React DOM component doesn’t have such an import for legacy reason but shouldn’t it be for sake of consistency ?
注意，由于传统原因，React DOM组件没有这样的导入，但不是出于一致性的考虑吗？
import { Div } from 'react-dom'; //To discuss only, don't do that ;) Based from the experience of the Airbnb’s library of React Native components, only 7 React Native APIs are widely used. Lots of the 70+ APIs are composition of these 7 primaries.
根据Airbnb的React Native组件库的经验，仅广泛使用了7种React Native API。 70多个API中有很多是这7个主要对象的组成。
Leland came with a proposal: these 7 APIs wrapped in an NPM package named react-primitives.
Leland提出了一个建议：这7个API包装在一个名为react-primitives的NPM软件包中。
View
View
Image
Image
Text
Text
Animated
Animated
Touchable
Touchable
Platform
Platform
StyleSheet
StyleSheet
Leland is aware that it isn’t perfect: the presence of Animated is questionnable. In the opposite, TextInput is not included despite it can’t be a composition of the 7 primitives.
Leland意识到这并不完美： Animated的存在令人怀疑。 相反，尽管TextInput不能由7个原语组成，但不包括在内。
But maybe an optional platform extension is the answer (inspired by the React Native ability to define platform-specific implementations by adding a suffix at the end of the file name).
但是答案可能是可选的平台扩展名(受React Native通过在文件名末尾添加后缀来定义特定于平台的实现的能力的启发)。
Take the checkbox example: Checkbox.js could contain a composition of primitives to design a checkbox on every platform where the checkbox doesn’t exist. And, as an optimization, Checkbox.web.js could contain only the input component from react-dom.
以checkbox为例： Checkbox.js可以包含一组原语，以在不存在该复选框的每个平台上设计一个复选框。 并且，作为一种优化， Checkbox.web.js可能仅包含react-dom的输入组件。
As if that were not enough convincing, Leland closed his talk with , showing how they treated the design tool as an additional platform without modifications in the code base thanks to primitives. Airbnb designers can design storyboards using the real library of React Native components.
似乎还不足以使人信服，Leland用结束了他的演讲，展示了他们如何将设计工具作为附加平台，而无原语在代码库中进行修改。 Airbnb设计师可以使用React Native组件的真实库来设计情节提要。
react-primitives:
react-primitives： :
In addition to making a great intro for each speaker during these 2 days, presented Snack for the Expo app in a lightning talk.
除了在这两天为每个演讲者做一个精彩的介绍外， 闪电演讲中向世博会应用程序展示了Snack。
Snack is the replacement of the former React Native playground (). The problem with rnplay-web was a very slow feedback loop. Code changes were sent to the server which had to run the React Native packager and sent back the output to the browser.
小吃取代了以前的React Native游乐场( )。 rnplay-web的问题是反馈回路非常缓慢。 代码更改已发送到必须运行React Native打包程序的服务器，然后将输出发送回浏览器。
With Snack, the code changes from the web editor are sent to the device and reexecuted directly.
使用Snack，来自Web编辑器的代码更改将发送到设备并直接重新执行。
Snack also includes a QR code generation to get your code running in the Expo app on your own device.
Snack还包含QR码生成功能，以使您的代码在您自己的设备上的Expo应用程序中运行。
Examples of the official React Native documentation has moved to Snack. For example:
官方React Native文档的示例已移至Snack。 例如： :
To play with the QR code generation, drag’n drop of Expo’s bridged components running on your own device in no time:
要玩QR码生成，请立即拖放运行在您自己设备上的Expo桥接组件： ：
In his lightning talk, spoke about code-splitting with react-loadable and its ability to preload a component using the static method preload().
在他的闪电演讲中， 谈到了带有react-loadable的代码拆分及其使用静态方法preload()预加载组件的能力。
There are 2 approaches regarding the preloading. The “passive” preloading is based on user’s intent. For example, a list page could preload the detail page because there are pretty good chances that the user want to open the detail page. This approach should be based on the analytics to avoid wasteful preloading.
关于预加载有两种方法。 “被动”预加载基于用户的意图 。 例如，列表页面可以预加载详细信息页面，因为用户很有可能要打开详细信息页面。 此方法应基于分析，以避免浪费预加载。
On the opposite, the “active” approach consists in a preload based on user’s action, like a mouse approaching a button (onMouseEnter event). For that case, Brandon created the library react-perimeter which define boundaries around a component and call a callback when they are breached (similar to a onMouseEnter event): useful to call the preload method.
相反，“活动”方法包括基于用户操作的预加载，例如鼠标接近按钮( onMouseEnter事件)。 在这种情况下，Brandon创建了库react-perimeter，该库定义了组件周围的边界，并在违反边界时调用回调(类似于onMouseEnter事件)：有助于调用preload方法。
react-loadable: react-perimeter:
react-loadable： : react-perimeter： :
Only 2 days after the conference, videos of the talks started be published on the conference YouTube channel, stay tuned on !
会议后仅两天，演讲视频就开始在会议YouTube频道上发布，敬请关注 ！
翻译自:
react vs 2017
转载地址：http://bvgwd.baihongyu.com/