19 個來自 2019 React Conf 的總結

原文: 19 Takeaways From React Conf 2019
做者:Anthony Morris
譯者:博軒
爲保證文章的可讀性,本文采用意譯

react-conf-header.png

React Conf ⚛️已經正式結束。有不少精彩的演講,人物,活動,固然還有美食。我還在整理整個活動,可是就此次會議而言,這是迄今爲止我參加過的最好的活動。javascript

開發者對於社區一般都會保持一顆敬畏之心。大會的志願者和組織者完成了不可思議的工做,使得每個參加會議的人都感到賓至如歸。他們的努力使得咱們每一個人都有一種歸屬感,這給我留下深入的印象。次日,甚至還會有一些css

內部
的活動。你是否想象過在會議上畫太小人像(想像下 《戰錘》)?我如今有過了!所以,對於全部相關人員,謝謝!

這篇文章收錄了一些此次 React Conf 中,我最喜歡的總結。每個主題都值得關注,因此我建議你看下 第一天次日 的視頻。個人文章底部爲全部演講中的話題都添加了時間戳。html

您可能會對列表中的某些項目感到驚訝。我也是!並不是全部內容都和技術相關,可是會有一個貫穿始終的共同線程。前端

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

湯姆·奧奇諾(Tom Occhino) 說完以後,我火燒眉毛的陷入了想象中。全部談話中提到的畫面都出如今個人腦海。我意識到我很是喜歡開發者工具和前端。java

React 旨在創造一種開發者體驗,使咱們可以更加輕鬆的學習並實現更增強大的功能,經過加快啓動和迭代來提升生產力,以及提高咱們開發軟件的規模。這些事情使我像 React 同樣。我以爲 Facebook 在交付方面作得很好。react

這一切有什麼意義呢?好吧,簡單來講就是服務於用戶體驗。咱們作的全部事情,以便咱們能夠幫助用戶提高工做效率,咱們應該致力於幫助他們以更加優雅的方式完成他們工做。咱們幫助他們完成實現目標的方式並不是老是閉門造車,而是多從用戶的角度考慮git

因爲 React 的流行,63% 的 JavaScript 開發者都在使用它,所以,團隊很是重視社區之類的事情。社區成員遵照 《參與者公約》 ,並提出批評。做爲一個社區,咱們應該可以接受批評而不是單純爲本身進行辯護。埃爾伯特·哈伯德(Elbert Hubbard)說:「爲了不批評,什麼都不說,什麼都不作,就什麼都不是。」 React 在作的事情,以及緣由很重要。這天然會引起爭議,但也會使得技術不斷進步。這會讓咱們的社區變得愈來愈好github

2.使人驚歎的易用性,性能以及併發模式!

你在使用 React 的時候,是否處理過焦點的問題?我有。焦點確實很重要 有不少緣由。它能夠幫助人們瀏覽頁面。這對於不使用鼠標的人來講,很是重要。這個話題稍後會再次提起,可是很高興看到 React 團隊讓焦點可訪問。web

會議期間讓我思考最多的事情之一就是性能。Facebook 必須處理咱們大部分人可能永遠都不會遇到的性能問題。可是他們從這些教訓中所學到的知識一樣能夠用來改善用戶體驗。若是性能很慢,則頁面加載速度並不重要。chrome

這方面的的一個例子就是鄭玉芝談話中提到的選擇混合 。你可能也據說過 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 上遇到的每一個人學到了不少東西。我很高興可以參加,並感到充滿驚奇和興奮。

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

如前所述,這些只是個人一些收穫。在爲期兩天的會議中,共享了許多庫,技術和哲學思想。我但願我能抓住他們所有!若是你明年去,你會明白個人意思。

若是您但願我擴展這些想法,我將很是樂意。伸出手,讓我知道!

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

時間戳

爲了方便您觀看,如下是爲期兩天的會議的細目。觀看全部演講並關注演講者!

第一天

次日

相關文章
相關標籤/搜索