react vs 2017

by Nicolas Cuillery

由Nicolas Cuillery

我在React Europe 2017上學到了什么 (What I learned at React Europe 2017)

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 Griffith Tchen Pan, just met among the audience, for his review of this article, as well as my team mates at M6 Web.

談到有趣的人，我要熱烈感謝剛在觀眾中遇到的Griffith Tchen Pan，感謝他對本文的評論，以及我在M6 Web上的隊友。

基調 (Keynote)

Those who came especially to hear news and updates about React could be satisfied: Andrew Clark opened the conference with the roadmap for React. All these updates can be resumed in a single name: React Fiber.

那些特別想聽到有關React的新聞和更新的人可能會感到滿意： Andrew Clark在會議上發布了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

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: https://github.com/acdlite/react-fiber-architecture

介紹React Fiber是打開會議的好方法。它的新功能受到社區的高度期待。要了解有關React Fiber的更多信息，請訪問： https : //github.com/acdlite/react-fiber-architecture

我從基準測試中學到了什么 (What I learned benchmarking React)

Dominic Gannaway 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的Dominic Gannaway展示了React軟件包的最新優化。受諸如Inferno(由他創建)和Preact之類的React輕量級克隆設計的啟發，他致力于使React包更輕，更快地加載。

Thanks to a new build system backed by Rollup, the React package gains 10% weight and is 9% faster to load.

多虧了Rollup支持的新構建系統，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 here).

它們還外部化了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 Google Lighthouse.

Dominic指出了在嘗試優化React軟件包時使用功能強大且一致的基準測試工具的重要性。他展示了一個有趣的“快照基準測試”工具，該工具將當前指標與運行在Google Lighthouse上的指標(程序包大小，初始加載時間，互動時間)進行了比較。

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: https://github.com/facebook/react/pull/9327Benchmark: https://github.com/facebook/react/pull/9465

要了解有關Dominic的工作的更多信息：新建系統： https : //github.com/facebook/react/pull/9327基準測試： https : //github.com/facebook/react/pull/9465

高品質JavaScript工具 (High quality JavaScript tools)

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 Christoph Pojer 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 Commander). It has been useful internally to consolidate their infrastructures and share best practices.

Jest已移至多包體系結構，其中一些已在Facebook的多個項目中使用：jest-haste-map，jest-snapshot，jest-validate(CLI選項解析器，如Commander )。在內部對鞏固其基礎架構和共享最佳實踐很有用。

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: https://facebook.github.io/jest/blog/2017/05/06/jest-20-delightful-testing-multi-project-runner.html

關于Jest 20的博客文章： https : //facebook.github.io/jest/blog/2017/05/06/jest-20-delightful-testing-multi-project-runner.html

更糟的是更好：JavaScript疲勞的好處 (Worse is better: the upside of JavaScript fatigue)

The point of this talk is that the JavaScript fatigue is a good thing, healthy for the ecosystem. Kevin Lacker started by remind us what the JavaScript fatigue is.

這次演講的重點是，JavaScript疲勞是一件好事，對生態系統而言是健康的。 Kevin Lacker首先提醒我們JavaScript疲勞是什么。

Hundreds of new librairies are announced each month on Hackernews. It’s impossible to take a look to everything. The good news is that you don’t have to: just pick the right thing.

每個月都會在Hackernews上宣布數百項新功能。看所有東西是不可能的。好消息是您不必：只需選擇正確的東西 。

From a principle conceived by Richard P. Gabriel in the eighties, the right thing has 4 golden characteristics:

從八十年代理查德·加布里埃爾(Richard P. Gabriel)構想的原理出發，正確的事情具有四個黃金特征：

Simplicity
簡單
Correctness
正確性
Consistency
一致性
Completeness
完整性

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: https://en.wikipedia.org/wiki/Worse_is_better

關于Richard P. Gabriel理論的出色文章： https ： //en.wikipedia.org/wiki/Worse_is_better

瓦比薩比 (Wabi Sabi)

This Japanese word designates the art of “beauty into imperfection”. Cheng Lou made a philosophic and very inspirational talk (for the second year in a row) 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 dead drop pattern 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 redux-observable which I can now describe as “a trade-off for the 20% of the cases Redux doesn’t cover”.

處于80％的系統中會給我們擺動的空間，這會增強我們的創造力和適應性。我在redux-observable上工作了幾個月，現在可以形容為“在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: http://lamport.azurewebsites.net/pubs/future-of-computing.pdf

萊斯利·蘭伯特(Leslie Lamport)的出版物： http : //lamport.azurewebsites.net/pubs/future-of-computing.pdf

流媒體如何增強React (How streaming can supercharge React)

Sasha Aickin 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.

Sasha Aickin在演講中介紹了一些有關初始渲染時間(在商業網站上+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 Paul Lewis the “uncanny valley”.

但是SSR還存在另一個問題：它導致第一次渲染(瀏覽器立即繪制服務器端渲染的標記)與“交互時間”(瀏覽器已加載包并且SPA處于打開狀態)之間存在延遲。 )。保羅·劉易斯 ( Paul Lewis)以滑稽的方式將這段時間稱為“不可思議的山谷”。

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 browser sends a request to the server,
瀏覽器向服務器發送請求，
The server fetches the data from the API,
服務器從API提取數據，
The server renders the markup,
服務器呈現標記，
The server returns the page with the markup.
服務器返回帶有標記的頁面。
The browser paints the markup and sends requests for the CSS and JS files. We have entered into the uncanny valley.
瀏覽器繪制標記并發送對CSS和JS文件的請求。我們進入了不可思議的山谷。
The server answers the requested files.
服務器回答請求的文件。
The browser loads and executes the bundle.
瀏覽器加載并執行捆綁軟件。
We’ve finally reached the end of the uncanny valley.
我們終于到達了奇異山谷的盡頭。

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現在更像是“流”，因此可以并行處理：

The browser sends a request to the server,
瀏覽器向服務器發送請求，
The server processes and returns the first chunk (the title)
服務器處理并返回第一個塊(標題)
While the browser paints and loads it, the server starts to process the 2nd chunk (the main content) and can even ask the API the data of the 3rd chunk (the comments) at the same time too.
當瀏覽器繪制并加載它時，服務器開始處理第二個塊(主要內容)，甚至可以同時向API詢問第三個塊的數據(注釋)。
The server returns the 2nd chunk
服務器返回第二個塊
And so on…
等等…

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 react-dom-stream), but, yes, it seems we had a glimpse of what the future of the SSR will be:

演講之后，我想到了很多疑問：如何在應用程序的每個頁面中定義塊？這是否意味著好的舊HTML模板會返回？ (我想我必須看一下Sasha的lib react-dom-stream )，但是，是的，看來我們對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: https://github.com/facebook/react/pull/9710

最近的請求顯示官方React回購中出現了一些問題： https : //github.com/facebook/react/pull/9710

Blog post about the uncanny valley: https://aerotwist.com/blog/when-everything-is-important-nothing-is/

有關不可思議的山谷的博客文章： https : //aerotwist.com/blog/when-everything-is-important-nothing-is/

閃電談話(第1天) (Lightning talks (day 1))

返回null; 約書亞·科莫(Joshua Comeau) (return null; by Joshua Comeau)

Joshua Comeau spoke about “renderless” components. Those components don’t render anything but enjoy the React lifecycle though.

Joshua Comeau談到了“無渲染”組件。這些組件除了呈現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 Web Speech API 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.

然后是一個更嚴重的示例：包裝Web Speech API的組件，該組件可大聲讀出文本輸入的內容。該組件能夠在讀取新內容之前中斷當前語音：由于新內容是道具，因此可以在componentWillReceiveProps輕松實現。

Joshua has gathered great explanations (as well as slides and examples) in his Github repository: https://github.com/joshwcomeau/return-null

Joshua在他的Github存儲庫中收集了很棒的解釋(以及幻燈片和示例)： https : //github.com/joshwcomeau/return-null

排毒：用于React Native的Graybox端到端測試和自動化庫 (Detox: Graybox End-to-End Tests and Automation Library for React Native)

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 Tal Kol and people at Wix put effort in automated tests and used the number 1 framework: Appium. 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天的時間。因此Tal Kol和Wix的工作人員致力于自動化測試，并使用了排名第一的框架： Appium 。由于測試必須在真實的??設備上運行，所以測試結果不令人滿意，它們非常慢，編寫復雜且不穩定(它們到處都帶有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 M6 Web. 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!

我在客戶公司M6 Web中遇到了與Appium完全相同的問題。由于閃電般的交流方式，無法詳細解釋Detox的內部，所以我們仍然有很多問題(它是否適用于brownfield應用程序？)，但我們肯定會自己嘗試Detox！

Repo: https://github.com/wix/detox

回購： https : //github.com/wix/detox

React Native上的嚴肅圖形 (Serious graphics on React Native)

Great way to close Day 1: a visual lightning talk full of cool stuff like video games, image filters, data viz, ... by James Ide from Expo.

結束第一天的好方法：一場視覺閃電般的談話，充滿了很酷的東西，例如視頻游戲，圖像過濾器，數據可視化……來自Expo的James Ide 。

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 gl-react that is compatible with React Native.

然后，詹姆斯展示了一些圖形界面，例如對攝像機視頻流的效果，視頻游戲以及使用與React Native兼容的現有庫gl-react創建的3D視圖示例。

GLView documentation: https://docs.expo.io/versions/v17.0.0/sdk/gl-view.html

GLView文檔： https : //docs.expo.io/versions/v17.0.0/sdk/gl-view.html

組成：超級大國解釋 (Composition: a superpower explained)

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. Nik Graf didn’t fall in that trap when he presented his talk about composition, inspired by his work on the color API of polish.

我發現函數式編程通常非常有用，簡潔和優雅，但是當代碼變得比以前更易讀和理解時，我們不應該陷入執行FP的陷阱……做FP。尼克·格拉夫(Nik Graf)在演講關于構圖的時候并沒有陷入這個陷阱，靈感來自他對波蘭色彩API的研究。

To illustrate the original problem, Nik presented an example of imperative code using Lodash (since the live video has been temporary removed from YouTube, I’ve rewritten similar code snippets):

為了說明原始問題，Nik展示了一個使用Lodash的命令式代碼示例 (由于實況視頻已從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 this excellent article).

這更加簡潔，但仍不完美，仍然有chain和value運算符(嚴重的是，他們在明確的Lodash鏈的末尾沒有忘記.value()嗎？)。而且，鏈式API殺死了部分導入Lodash的能力(請參閱這篇出色的文章 )。

Real composition allows to define a pipe with Ramda, lodash/fp:

實際組合物允許定義與管道Ramda ， lodash / FP ：

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: https://facebook.github.io/react/docs/higher-order-components.html

React有關成分和HoC的文檔： https ://facebook.github.io/react/docs/higher-order-components.html

作為平臺進行React (React as a Platform)

It’s a well-known fact that Airbnb makes an extensive use of React and React Native. Leland Richardson pointed out that it was a big step forward:

眾所周知，Airbnb廣泛使用了React和React Native。 Leland Richardson指出這是向前邁出的一大步：

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, React Native for Web had come, followed by Windows, Ubuntu, VR, …

Leland認為我們可以實現這一目標。 React Native令人大開眼界：React可以處理多個平臺。然后， React Native for Web出現了，隨后是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的輸入組件。

<input type="checkbox">

As if that were not enough convincing, Leland closed his talk with react-sketchapp, showing how they treated the design tool Sketch 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用react-sketchapp結束了他的演講，展示了他們如何將設計工具Sketch作為附加平臺，而無需借助原語在代碼庫中進行修改。 Airbnb設計師可以使用React Native組件的真實庫來設計情節提要。

react-primitives: https://github.com/lelandrichardson/react-primitives

react-primitives： https : //github.com/lelandrichardson/react-primitives

閃電談話(第2天) (Lightning talks (day 2))

世博小吃 (Expo Snack)

In addition to making a great intro for each speaker during these 2 days, Brent Vatne presented Snack for the Expo app in a lightning talk.

除了在這兩天為每個演講者做一個精彩的介紹外， Brent Vatne還在閃電演講中向世博會應用程序展示了Snack。

Snack is the replacement of the former React Native playground (rnplay-web). 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 )。 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: http://facebook.github.io/react-native/releases/next/docs/text.html

官方React Native文檔的示例已移至Snack。例如： http : //facebook.github.io/react-native/releases/next/docs/text.html

To play with the QR code generation, drag’n drop of Expo’s bridged components running on your own device in no time: https://snack.expo.io/

要玩QR碼生成，請立即拖放運行在您自己設備上的Expo橋接組件： https ： //snack.expo.io/

用于React應用程序的更智能的代碼拆分和預加載 (Smarter code-splitting and preloading for React applications)

In his lightning talk, Brandon Dail spoke about code-splitting with react-loadable and its ability to preload a component using the static method preload().

在他的閃電演講中， Brandon Dail談到了帶有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: https://github.com/thejameskyle/react-loadablereact-perimeter: https://github.com/aweary/react-perimeter

react-loadable： https : //github.com/thejameskyle/react-loadable react-perimeter： https : //github.com/aweary/react-perimeter

Only 2 days after the conference, videos of the talks started be published on the conference YouTube channel, stay tuned on https://www.youtube.com/channel/UCorlLn2oZfgOJ-FUcF2eZ1A/videos !

會議后僅兩天，演講視頻就開始在會議YouTube頻道上發布，敬請關注https://www.youtube.com/channel/UCorlLn2oZfgOJ-FUcF2eZ1A/videos ！