19 個來自 2019 React Conf 的總結

joking_zhang發表於2019-11-12
React
原文：19 Takeaways From React Conf 2019
作者：Anthony Morris
譯者：博軒
為保證文章的可讀性，本文采用意譯

react-conf-header.png

React Conf ⚛️已經正式結束。有很多精彩的演講，人物，活動，當然還有美食。我還在整理整個活動，但是就這次會議而言，這是迄今為止我參加過的最好的活動。

開發者對於社群通常都會保持一顆敬畏之心。大會的志願者和組織者完成了難以想象的工作，使得每一個參加會議的人都感到賓至如歸。他們的努力使得我們每個人都有一種歸屬感，這給我留下深刻的印象。第二天，甚至還會有一些內部的活動。你是否想象過在會議上畫過小人像（想像下《戰錘》）？我現在有過了！因此，對於所有相關人員，謝謝！

這篇文章收錄了一些這次 React Conf 中，我最喜歡的總結。每一個主題都值得關注，所以我建議你看下 第一天 和 第二天 的視訊。我的文章底部為所有演講中的話題都新增了時間戳。

您可能會對列表中的某些專案感到驚訝。我也是！並非所有內容都和技術相關，但是會有一個貫穿始終的共同執行緒。

1. 服務於開發者體驗的使用者體驗

在 湯姆·奧奇諾（Tom Occhino） 說完之後，我迫不及待的陷入了想象中。所有談話中提到的畫面都出現在我的腦海。我意識到我非常喜歡開發者工具和前端。

React 旨在創造一種開發者體驗，使我們能夠更加輕鬆的學習並實現更加強大的功能，通過加快啟動和迭代來提高生產力，以及提升我們開發軟體的規模。這些事情使我像 React 一樣。我覺得 Facebook 在交付方面做得很好。

這一切有什麼意義呢？好吧，簡單來說就是服務於使用者體驗。我們做的所有事情，以便我們可以幫助使用者提升工作效率，我們應該致力於幫助他們以更加優雅的方式完成他們工作。我們幫助他們完成實現目標的方式並非總是閉門造車，而是多從使用者的角度考慮。

由於 React 的流行，63% 的 JavaScript 開發者都在使用它，因此，團隊非常重視社群之類的事情。社群成員遵守 《參與者公約》 ，並提出批評。作為一個社群，我們應該能夠接受批評而不是單純為自己進行辯護。埃爾伯特·哈伯德（Elbert Hubbard）說：“為了避免批評，什麼都不說，什麼都不做，就什麼都不是。” React 在做的事情，以及原因很重要。這自然會引發爭議，但也會使得技術不斷進步。這會讓我們的社群變得越來越好。

2.令人驚歎的易用性，效能以及併發模式！

你在使用 React 的時候，是否處理過焦點的問題？我有。焦點確實很重要 有很多原因。它可以幫助人們瀏覽頁面。這對於不使用滑鼠的人來說，非常重要。這個話題稍後會再次提起，但是很高興看到 React 團隊讓焦點可訪問。

會議期間讓我思考最多的事情之一就是效能。Facebook 必須處理我們大部分人可能永遠都不會遇到的效能問題。但是他們從這些教訓中所學到的知識同樣可以用來改善使用者體驗。如果效能很慢，則頁面載入速度並不重要。

這方面的的一個例子就是鄭玉芝談話中提到的選擇混合 。你可能也聽說過 Suspense，這些都將改善整個 Web 上的使用者體驗。

併發模式

想象一下，使用 React 做一個根據使用者輸入而改變的可過濾列表。你必須使用節流或者防抖進行優化，除非你不在意效能。

併發模式 將使 React 能夠對低優先順序的工作中斷響應，從而使得 React 應用程式具備更高的響應速度。這使得使用者輸入之類的事情，比重新渲染列表之類的事情具備更高的優先順序。React 可以使得幾個工作中的狀態同時更新。這將幫助我們消除抖動以及過於頻繁的 DOM 更新。它還將使我們能夠優先處理諸如懸停和文字輸入之類的互動。我們知道使用者希望這些內容能夠快速的被處理，否則，他們會感到遲鈍。

React 團隊分享了許多關於併發模式的示例 ，我建議您檢視一下。

3. CSS-in-JS-at-FB

對於 Frank Yan 宣佈 Facebook 正在構建自己的 CSS-in-JS 庫，我很感興趣。起初我以為，我們目前的庫還不夠嗎？這使我們有機會進一步瞭解 Facebook 大規模面臨的一些問題，以及他們解決問題創造性的方式。

維護 CSS 很快就會失去控制。讓我們看下面的例子：

.blue { color: blue; }

.red { color: red; }
// 展示為紅色
<span class="red blue">
  Which color will I be?
</span>

在此示例中，我們希望如果文字看到文字是 blue。因為它排列在類宣告的第二位，因此我們希望它應該具有優先權。但是事實並非如此。.red 排列在樣式表的第二位，所以會優先展示為紅色。如果這些位於不同的樣式表之中，則他們在頁面中的載入順序將很重要。

這個例子雖然很 “幼稚”，例子看起來也很簡單，但是很快就會失控。Facebook 旨在通過新的類庫來解決諸如特異性戰爭，主題化和可訪問性之類的問題。

演講中的一些有趣的細節：

  • 開發人員可以以畫素為單位進行編碼，但是其工作可以在 REM 中進行編譯。
  • 他們通過執行型別檢查（捕獲和修復錯別字，檢測並刪除未使用的樣式。避免跨瀏覽器的陷阱）來創造安全性。
  • 向開發人員展示可訪問性的錯誤。

accessibility-violation

  • 元件具有預設樣式，並且可以被覆蓋（包括型別安全！）
  • 重複規則校驗，減少 CSS 檔案體積（Facebook 在最近的重構中，將檔案從 413kb 改寫為 74kb）

原子 CSS

每個類的建立都僅有一個唯一的屬性值對。這用於優化元件

.c0 { color: blue; }
.c1 { color: red; }
.c2 { font-size: 16px; }
//生成的元件（預先優化）

// Generated Component (Pre-Optimized)
const styles = {
  blue: {color: 'c0'},
  default: {color: 'c1', fontSize: 'c2'},
};
function MyComponent(props) {
  return (
    <span className={styles(
      'default',
      props.isBlue && 'blue',
    )}>
      Hello World!
    </span>
  );
}

這個例子展示了 CSS 的原子性。它還展示瞭如何使用 props 來設定 span 標籤的顏色。但是，此程式碼可以得到進一步優化。

// 不再需要樣式塊
function MyComponent(props) {
  return (
    <span className={styles(
      (props.isBlue ? 'c0 ' : 'c1 ') + 'c2 '
    )}>
      Hello World!
    </span>
  );
}

這些事情非常有趣，我期待著將來它們的庫被髮布。

4.資料驅動的JavaScript

您是否曾經想過如何使頁面感覺更快？早點互動？當然有！阿什利·沃特金斯（Ashley Watkins）同樣做到了。她真的讓我在思考如何調整資料獲取的方法來改善使用者體驗。我已經開始對 Relay 感興趣，但她讓這種感覺持續升級。

分階段程式碼分割

您應該可以猜到，Facebook 的工程師一直在努力確保他們的 FMP（首次有效繪製） 儘可能的快速。他們執行此操作的方法之一就是“分階段進行程式碼拆分”。

使用這種方法，您可以進行一次阻止下載並分階段交付。例如，如果您參考 Facebook 的方式，則可以將其分為三個階段。

  • 1.載入中
  • 2.顯示
  • 3.分析工具

這些階段中的每一個階段都可以有自己的程式碼獲取以及渲染。FMP 所需的所有資料都可以在載入階段獲取其他程式碼的同時獲取。

phased-code-splitting

到第一個有意義的畫面的時間

為了使您的使用者體驗達到最佳狀態，您應該考慮首屏載入時間。基本上，這是主要內容顯示在頁面上的時間。您可以檢視和衡量許多指標以縮短載入時間，但是 FMP 還是很顯眼。

Relay 允許您使用 GraphQL 進行流式查詢。這將使您可以將某些資料標記為關鍵資料，而將其他資料標記為非關鍵資料。然後，您可以首先從伺服器獲取最重要的內容，並在獲取其餘資料的同時進行顯示。使用這種方法，您可以在內容到達時，再對其進行渲染！

資料驅動的程式碼分割

這個讓我有些震驚。Relay 功能強大，這毫無疑問。Relay 具有一項新功能，可讓您擴充套件查詢條件以表達需要呈現特定資料型別所需的元件程式碼。? 您可以將程式碼視為資料。當伺服器解析您的 GraphQL 查詢時，它可以讓客戶端知道需要下載哪些元件程式碼，以便更快地獲取它！

阿什利的演講令人感到難以置信，但她保證這些事情僅僅是個開始。我還沒有使用過 Relay，但我很高興開始使用它，我敢打賭，您也會這樣做（尤其是當您聽到更多有關它可以做什麼的資訊時）。

5.解決世界的飢餓

第一天的開始主要來自 Facebook 工作人員的大量演講。從技術的角度，這是令人興奮的。我們看到生態系統中有許多即將釋出的功能，以幫助我們改善使用者體驗。

Tania Papazafeiropoulou 稍微調整了話題，以向參會者介紹世界飢餓和她正在研究的一種很酷的產品 OLIO。他可以幫助人們分享食物，而不是浪費食物，而你猜不到它是由 React 所支援的。

發現有浪費三分之一的食物被浪費是令人沮喪的。重要的是，我們僅用來自美國，英國，歐洲的 25% 的食物就可以解決世界飢餓的問題。這些清晰的資料，使得解決世界飢餓問題成為了可能，聽到一個團隊正在為這件事努力真的太棒了。

這次並沒有宣傳 React 的新功能，但是它使得 React 更加優秀。React (和 React Native) 使得 Tania 的團隊可以快速構建他們的產品，並且產生積極地影響。

6.使 REST 更好（和更安全）

RESTful APIs 並不是一個新的熱門?的概念。它們於2000年正式被定義，自那時開始已經成功的投入使用。話雖如此，REST 確實有一些需要挑戰的東西。

Facebook 通過 GraphQL 應對了這些挑戰。GraphQL 為我們提供了對資料更加可理解的定義。它使客戶有能力僅獲得所需的東西。這是實現更快渲染時間的絕佳方法，因為您不必下載太多資料！

Tejas Kumar 很好地總結了差異（請觀看他的演講以便更深入地瞭解）：

REST

  • ❌ 資料格式不規範
  • ❌ 猜謎遊戲（如何判定一個失敗的請求，400，401，還是 404？）
  • ❌ 無意義的對話
  • ❌ 無合約協議

GraphQL

  • ✅ 規範的資料格式
  • ✅ 沒有猜謎遊戲
  • ✅ 有意義的對話（由使用者定義）
  • ✅ 強力的合同協議

我們中的許多人都喜歡 GraphQL，但有時它不是 API 的選擇。Tejas和他的團隊開發了一種工具來消除 REST 的一些陷阱。它包括 Swagger 和 使用 OpenAPI 規範的生成程式碼。

我不相信我會完全按照他說的去做，但他的講話給我留下了持久的印象。講真地，去看他的演講！

7.React 的引擎（構建自定義渲染器）

如果您曾經演示過以前編寫的程式碼，則知道它經常出錯。蘇菲·阿爾珀特（Sophie Alpert） 構建了 React 渲染器，並向我們傳遞這個過程所需要的知識。

我不認為自己是一個 React 專家（呵呵 ?）。我從沒看過 React 程式碼庫。我一直以為那將超越我。在我繼續學習和掌握 React 的過程中，我將繼續深入研究並最終進入程式碼庫本身。索菲（Sophie）在 React Conf 舞臺上實時構建自己的自定義渲染時，似乎沒有那麼驚人。

除了向學習 Sophie 的之外，我覺得自己對 React 渲染器的工作原理只有一點了解。她沒有讓我撓頭。一切都簡單地解釋，並且清楚地展示了出來。還有什麼比這更棒的呢？

願演示之神永遠喜歡 Sophie！

8.本地化（這太重要了！）

作為一個以英語為母語的人，我必須承認，在開發產品時，我不會第一時間想到本地化。值得慶幸的是，我意識到了這一點，並將在未來更加認真地對待它。

我認為本地化經常會被忽視，因為我們專注於像我們這樣的使用者。你的使用者都和你一樣，這是不現實的！這就是為什麼我們需要進行使用者測試，獲得使用者反饋，讓產品對所有型別的使用者，都更具包容性。

去年，納特·艾莉森（Nat Alison）提出了一個問題“ React 是否被翻譯了？”。當她最初提出這個問題時，答案是否定的。

為什麼這麼重要？恩，納特說得很好。如果只有講英語的人可以訪問 React ，那麼有多少人無法使用這些工具來開發出令人讚歎的產品？只讓說英語的人構建我們的數字世界，我們會損失多少？世界上只有20％的人口說英語。如果我們不幫助別人使用 React，這將是我們自己的損失！

is-react-translated-yet

納特（Nat）和成千上萬的人在過去一年中取得了令人難以置信的成就。還有更多工作要做，如果您會說雙語，希望您也可以提供幫助！

9.無障礙馬拉松

就像本地化一樣，可訪問性可能很困難。在開發可訪問性時，您必須以不同的方式思考。您必須考慮更多的受眾，考慮可能與您不同的人。有時候這很困難，但我們都能做到。

跑馬拉松??‍♂️是另一個可能很困難的例子。根據 RunRepeat 的統計，2018年有 1,298,725 人完成了馬拉松比賽。他們並非是完全有能力才去做的。他們從小處著手，並努力達到目標。

這就是我們處理可訪問性的方法。如果您是從頭開始，採取這種方法將消除一些不堪重負的感覺。我對 React Conf 的最喜歡的事情之一就是從新的角度學習軟體開發和世界。布列塔尼·費恩斯特拉（Brittany Feenstra）是幫助我擴大視野的人之一，我想進一步思考無障礙環境。

我不會在一夜之間完成無障礙馬拉松比賽，但今後每天我可以做更多的事情。值得慶幸的是，在此過程中有很多優秀的工具可以幫助我。

10.您不需要Redux（對嗎？）

2019年，有許多不同的方法來管理 React 狀態（甚至包括 easy-peasy）。

有這麼多的選擇，很難知道什麼才是正確的選擇。不幸的是，正確的選擇將取決於你自己。請記住，開發人員體驗是服務於使用者體驗。知道了這一點，我喜歡通過儘可能簡單，並隨我的原始決定而改變的方式來進行狀態管理。

我很高興 React 現在內建了很多選項。使用 Context 和 Hooks ，您可以做很多事情而無需依賴其他依賴項。

為了快速行動並完成目標，您必須願意放棄以前完成的工作。當您的產品與眾不同時，您需要愛上重構並推翻之前對您有用的決策。我認為 React 狀態的許多選擇都反映了這一點。有些選項需要很多樣板，有些則不需要。有些是需要包裝的，有些不是。現在選擇適合自己的感覺，並在以後需要時進行調整。

11.時間旅行到1999

當天的最後一次演講讓我對標題感到興趣。1999年程式設計是什麼樣的？那時我才九歲。有些人從九歲開始編碼。我不是其中之一。?

這場談話是另一個確實需要關注的話題。李·拜倫（Lee Byron）提供了一顆精心打磨的寶石。在 PHP 和 LAMP 技術棧成為 Web 開發工具的時候，他帶領我們走過了一段時期。對於那些沒有在1999年進行編碼的人，他解釋了導致 Facebook 開發諸如 React ， GraphQL 和 Relay 等工具的演變。對於當時正在編碼的人心中會充滿留戀。

我一直尊重 Facebook 所做的工程工作，但是這次演講使一切都變得正確更加清晰。使用 React 感覺就像是一種特權，現在我知道特權的來源。我受到像 Lee 這樣的人的啟發，並將繼續為社群做事。

12.即使開發工具也與UX有關

第二天會議在 Brian Vaughn 的闡述 中繼續進行。如果使用 React 構建內容，則可能已經使用了React Dev Tools。他們無疑幫助我擺脫了自己製造的混亂局面。

React Dev Tools 得到了全面的重寫，其中包括：

  • 更好的效能
  • 新的API支援
  • UX新功能

看，即使開發工具也專注於出色的UX！

團隊為幫助不熟悉的專案同學熟悉專案，進行的更改使我印象深刻。儘管您可能從未接觸過陌生的程式碼，但我們都知道，即使是我們自己的程式碼，隨著時間的流逝也會顯得陌生。現在，我們可以看到 prop 如何流經元件，如何過濾元件樹，深入檢查元件以及如何將 hook 與 dev tool 一起使用。我喜歡看到的另一件事是 suspense 的轉變。這個功能看似非常簡單，但很快就會變得無價。

連同共享配置檔案一起，新的開發者工具使查詢原因的工作變得更加容易。那裡有類似的工具，但是現在我們可以直接在開發工具中瞭解您的渲染。

還有很多其他很棒的補充，我建議您自己去探索它們。

13.可疑資料（Relay 很棒）

我想我可能要接力 Relay 了。實際上，我很晚開始使用 GraphQL。在我的輔助專案中，我一直在使用 GraphQL ，我非常喜歡它。在這次會議之後，我將探索 Relay，並利用組合提供的功能。

React Suspense 希望使我們能夠顯示某些 UI，而無需等待所有 UI 準備就緒ready。

讓我們看一個元件的基本示例，該元件在獲取資料時顯示載入狀態（使用 Suspense）：

const Composer = (props) => {
  const data = useQuery(graphql`
    query ComposerQuery {
      me {
        photo {
          uri
        }
      }
    }
  `, variables);
  return (
    <div>
      <img src={data.me.photo.uri} />
    </div>
  );
}
const Home = (props) => (
  <Suspense fallback={<Placeholder />}>
    <Composer />
  </Suspense>
);

在此示例中，我們有一個 Composer 元件，該元件可獲取個人資料圖片的 URI，然後顯示它。您可以在 Home 將 Composer 包裝在一個 Suspense 塊中的元件中看到。然後，當資料正在載入時，Placeholder 將被渲染。可以將這種模式視為 “渲染時獲取”。

使用此模式，載入順序如下：

fetch-on-render

如您所見，這使我們能夠輕鬆處理資料載入。我們可以通過使用佔位符或 Loading 等載入元件來提供更好的使用者體驗。

上面的模式已經帶來了很多收益和靈活性。但是，Facebook 團隊不喜歡您必須渲染以找出元件所需的資料。為了解決這個問題，他們開始使用一種稱為 “獲取資料時渲染” 的模式。

從本質上講，為了啟用 “按需渲染” 功能，Facebook 團隊已分解 useQuery 為兩部分。它分為 preloadQuery 和 usePreloadedQuery 。這到底是什麼意思呢？

preloadQuery

該 API 將獲取資料併為結果提供參考。它沒有提供實際資料。

您將在顯示新使用者介面的同一事件處理程式中呼叫此 API。例如，如果使用者單擊將觸發導航到新頁面的連結，則將使用我們處理單擊的事件處理程式 preloadQuery 。將滑鼠懸停在某處上以開啟工具提示將是您呼叫此 API 的另一個示例。該 onHover 事件處理程式呼叫 preloadQuery 。

usePreloadedQuery

該 API 獲取 preloadQuery 呼叫結果。實際上，它本身不會進行任何資料獲取。它檢視的當前狀態 preloadQuery。如果準備就緒，它將顯示結果。如果尚未準備就緒，它將暫停。如果查詢失敗，則可能引發錯誤。

無論發生什麼情況，usePreloadedQuery 都永遠不會觸發新的提取。這使其高效且可預測。

代替使用這兩個 API，useQuery 將提供如下所示的載入順序：

render-as-you-fetch

我絕對建議您聽喬·薩沃納（Joe Savona）解釋上面我總結的概念。他講得更好，而且更深入。這是我最喜歡的演講之一，因為我對這種模式所帶來的可能性感到興奮，並且迫不及待地想嘗試一下。

14. React是小說

詹恩·克賴頓（Jenn Creighton）在會議上發表了我最喜歡的哲學演講。她從事創造性寫作工作。創意寫作一直是我的最愛。像詹恩一樣，我曾經幻想成為作家。她在演講中解釋了一個概念，該概念以一種有趣（且出乎意料）的方式轉化為編碼。

顯示，不告訴

讓我們看一下傳達相同含義的兩種方式（由Jenn提供）。

她累了。

她的步伐變得緩慢，隨著一步一步接近床，她的臉先接觸到了床墊，身體也感覺更加沉重。

相同的想法，對不對？她累極了。哪一個功能更強大？好吧，這很明顯。作為軟體工程師，我們經常陷入困境。我們抽象，抽象，抽象，直到我們儘可能地榨乾自己。

在大多數情況下，我會盡力避免程式碼重複。該原理很有意義，但是，就像編寫規則一樣，有時我們需要打破軟體開發規則。讓我們比較兩個獲得相同結果的不同程式碼。

const Nav = ({ links }) => (
  <nav>
    {
      links.map(link => (
        <Link to={link.to}>{link.name}</Link>
      ))
    }
  </nav>
);
const Header = () => {
  const links = [
    { name: 'Home', to: '/home' },
    { name: 'Settings', to: '/settings' },
  ];
  return (
    <>
      <Nav links={links} />
    </>
  );
}

這看起來似乎很好用，但是如果我們想新增一個導航項，該怎麼辦？例如登入按鈕。

const links = [
    { name: 'Home', to: '/home' },
    { name: 'Settings', to: '/settings' },
    { name: 'Login', to: '??' },
  ];

我們的 Nav 元件無法處理這種情況。我們可以很容易地實現一種處理它的方法，但是這很容易失控。我們可以將 Nav 元件重構為如下所示：

const Nav = ({ links }) => (
  <nav>
    {
      links.map(link => {
        return link.to
          ? <Link to={link.to}>{link.name}</Link>
          : <a onClck={link.onClick}>{link.name}</Link>
      })
    }
  </nav>
);

這將起作用，但是在難以推理 Nav 元件之前，我們將覆蓋多少個邊緣情況？我們可以用另一種方式重寫 Header 元件。

const Header = () => {
  const links = [
    { name: 'Home', to: '/home' },
    { name: 'Settings', to: '/settings' },
    { name: 'Login', to: '??' },
  ];
  return (
    <nav>
      <Link to="/home">Home</link>
      <Link to="/settings">Settings</link>
      <a onClick={onSelectLogin}>Login</a>
    <nav/>
  );
}

我簡化了詹恩在演講中講的例子，但我認為這很重要。第二 Header 部分更容易推論。即使我們現在可能重複一遍，抽象也沒有帶來太大的好處。如果我們想將一個 Icon 元件新增到其中一個連結中，則不必再處理 Nav 元件中的所有極端情況，只需將其新增到所需位置即可。

詹恩（Jenn）還引用了尼爾·蓋曼（Neil Gaiman）的一句話，說我不得不分享。

請記住，或早或晚，在達到完美之前，你必須放手去做，繼續接下來的事。

在構建心理健康寫作平臺 Wrabit 的時候，我一直在練習，使得自己變得足夠好。有時候，這讓我覺得自己不像一個開發人員。有時候讓我感到自己的懶惰。最後，我將介紹易於理解的內容，可以提供的內容以及以後可以隨時重構的內容。

正如 Jenn 所說，重構並非失敗。她的演講非常巧妙地將創意寫作與程式設計編織在一起，我一定會再看一遍。

15. UX驅動的流體動畫

我還沒有製作太多的動畫。我設想了一個未來，我將從 Dribbble（動畫和所有動畫）中獲得出色的 UI 設計，並進行實踐設計。動畫絕對是設計色情片中令人愉悅的一點，但是即使如此，我們在實現的時候也要牢記使用者體驗。

像大多數談話一樣，亞歷克斯·霍爾切克（Alex Holachek）讓我以新的方式思考。我喜歡UI互動。它們讓我感到內心溫暖而模糊。看著他們時，我沒有考慮所有使用者而感到內疚。

精美的動畫如何對使用 Nokia 6 的使用者起作用？來自亞馬遜的 283.97加元，我買得起新 iPhone 之前的價格要高出很多倍。我猜很多其他人都在同一陣營。

亞歷克斯（Alex）幫助我記住了更多關於平均值的思考。平均電話，平均資料速度。建立平均和高階將永遠是好的。

此外，event.preventDefault() 還會對滾動產生不良影響。

16.反覆體驗

如果您無法確定，那麼今年的會談內容千變萬化。盧卡·德馬斯科（Luca Demasco）通過與 Zach Rispoli 合作開發 Wick 編輯器，向我們展示了迭代過程，從而保持了新鮮感。

Wick 編輯器是一個免費的開源工具，可用於建立遊戲，動畫以及您能想到的其他任何東西。當Luca展示當前版本時，UI 確實給我留下了深刻的印象。看起來很直觀，並且具有很多功能。並非總是如此。

盧卡（Luca）和朋友通過不斷的迭代達到了今天的狀態。它們也不只是為了迭代而進行迭代。他們將Wick帶入了許多不同的環境（學校，圖書館等），並使介面出現在許多不同的使用者（初學者，中級使用者，年輕人，老人）面前。他們採取了獲取，保留，擴張 （Laser-Focused Approach） 的方法，並收集了很多反饋，幫助 Wick 成為今天的樣子。

當我考慮如何迭代自己的產品時，過程中的誠實啟發了我。如何快速啟動並有意地迭代？我沒有那種經驗，所以有時信心會使我迷失，但這是我很高興採取的一個過程。看到像 Luca 這樣的人分享他的經驗，這使我感到鼓舞，我感謝會議期間每個人都真誠的分享。

17.簡單事物的複雜性

您是否使用 react-select？沒有？那可能只有你不知道了。

該元件在 GitHub 上擁有超過18000個星標。每週有 150 萬次下載。好多啊。

您可能不會想到一個簡單的 React 元件可能會那麼複雜。當然，你會錯的。傑德·沃森（Jed Watson）開發了一個漂亮的 React 元件，並且很好地實現了它的目的。它具有很多功能，並且開箱即用。

傑德走了一段漫長的（有時是艱苦的）道路，才實現了 react-select。他對開發大規模的流行的開源專案有了深刻的見解。他還展示了簡單的事情通常可能非常複雜。

當 Jed 展示了 react-select 到 v2.0 的演變時，我受到了 Jed 的啟發。他重申了重構的重要性以及如果您不想追求完美，就可以隨時停止。

18.優雅的透明度

政府支出是一個重要的話題。我們應該看到我們的稅收去向，以便使政府負責。

Lizzie Salita 證明了政府網站可以高效，易於使用且美觀。當她演示 USAspending.gov 支出瀏覽器時，我真的很驚訝。將其與加拿大版本進行比較，您將獲得一個示例，該示例可以使用 React 重構來提升使用者體驗。

我正在慢慢地開始涉足政治領域。儘管我一直在努力保持足夠的知情權以便投票，但我還有很多事情要做。擁有諸如 USAspending.gov 之類的工具，將使它變得更加輕鬆有趣。我認為我們應該繼續開發這樣的工具，以使每個人都能瞭解最新情況，以便我們所有人都可以參與塑造我們的未來。

19.奇蹟驅動的開發

會議的最後一次演講真讓我震驚。像亞歷克斯·安德森（Alex Anderson）一樣，我是太空的忠實粉絲。亞歷克斯（Alex）建立了一個瘋狂的複雜的星艦模擬器，名為Thorium。

Thorium模擬器使諸如獅門空間中心之類的許多組織能夠為各種人提供與 STEM 相關的活動。這些空間中心使學生能夠通過高度互動性和教育性的小組活動來成長。

React Conf 上幾乎所有的演講，人們都在為正當理由做著鼓舞人心的事情。亞歷克斯的工作之所以突出，是因為他的熱情從他所說的每句話中洩漏出來。他熱愛自己的工作，並且是一位非常有才華的工程師。他正在使用可用的技術為孩子和成年人建立良好的體驗。

我最喜歡從 Alex 的演講中脫穎而出（這需要我花一點時間才能完全理解）是奇蹟驅動開發的概念。您是否想過技術的可能性？那你有什麼能力呢？?

這些型別的問題驅使我們建立有趣，愉快和真正美好的體驗。這些型別的問題使 Facebook 的工程師和世界各地的公司可以利用技術來塑造我們的世界。

我從今年在 React Conf 上遇到的每個人學到了很多東西。我很高興能夠參加，並感到充滿驚奇和興奮。

我等不及要看什麼奇蹟驅使我成長！

如前所述，這些只是我的一些收穫。在為期兩天的會議中，共享了許多庫，技術和哲學思想。我希望我能抓住他們全部！如果你明年去，你會明白我的意思。

如果您希望我擴充套件這些想法，我將非常樂意。伸出手，讓我知道！

最後，更不用說德文·林賽了。她給了我們笑聲，糖果和內部的活動。沒有她，這次會議就不會一樣。

時間戳

為了方便您觀看，以下是為期兩天的會議的細目。觀看所有演講並關注演講者！

第一天

第二天

相關文章