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

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

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

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

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

9.無障礙馬拉松

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

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

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

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

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

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

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

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

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

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 將被渲染?？梢詫⑦@種模式視為 “渲染時獲取”。

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

如您所見，這使我們能夠輕松處理數據加載。我們可以通過使用占位符或 Loading 等加載組件來提供更好的用戶體驗。

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

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

preloadQuery

該 API 將獲取數據并為結果提供參考。它沒有提供實際數據。

您將在顯示新用戶界面的同一事件處理程序中調用此 API。例如，如果用戶單擊將觸發導航到新頁面的鏈接，則將使用我們處理單擊的事件處理程序 preloadQuery 。將鼠標懸停在某處上以打開工具提示將是您調用此 API 的另一個示例。該 onHover 事件處理程序調用 preloadQuery 。

usePreloadedQuery

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

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

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

我絕對建議您聽喬·薩沃納（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 上遇到的每個人學到了很多東西。我很高興能夠參加，并感到充滿驚奇和興奮。

我等不及要看什么奇跡驅使我成長！

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

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

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