2019年8月8日,咱們發佈了React 16.9。它包含幾個新功能,錯誤修正和新的棄用警告,以幫助準備將來的主要版本。
新的版本:javascript
重命名不安全的生命週期方法前端
一年多之前,咱們宣佈從新命名不安全的生命週期方法:java
componentWillMount → UNSAFE_componentWillMount componentWillReceiveProps → UNSAFE_componentWillReceiveProps componentWillUpdate → UNSAFE_componentWillUpdate
React 16.9不包含重大更改,舊版本名稱在此版本中繼續有效。可是,當您使用任何舊名稱時,您將看到警告:react
警告:componentWillMount已重命名,不建議使用。web
正如警告所示,每種不安全方法一般都有更好的方法。可是,您可能沒有時間遷移或測試這些組件。在這種狀況下,咱們建議運行一個「codemod」腳本,自動重命名它們:npm
npx react-codemod rename-unsafe-lifecycles
(注意它說npx,不是npm。npx默認狀況下是Node 6+附帶的實用程序。)編程
運行此codemod
將替換舊名稱,如componentWillMount
新名稱,如UNSAFE_componentWillMount
:數組
Codemod
在行動瀏覽器
新的名字 UNSAFE_componentWillMount
將繼續在React 16.9和React 17.x中運行。可是,新的UNSAFE_前綴將幫助具備問題模式的組件在代碼審查和調試會話期間脫穎而出。(若是您願意,能夠經過選擇嚴格模式進一步阻止他們在您的應用中使用。)安全
注意
詳細瞭解咱們的版本政策和對穩定性的承諾。
棄用javascript:
網址
以...開頭的URL javascript:是一個危險的攻擊面,由於它很容易在標籤中意外包含未通過類型化的輸出 a
標籤,並建立一個安全漏洞:
const userProfile = { website: "javascript: alert('you got hacked')", }; // This will now warn: <a href={userProfile.website}>Profile</a>
在React 16.9中,此模式繼續有效,但它將記錄警告。若是您使用javascript:URL做爲邏輯,請嘗試使用React事件處理程序。(做爲最後的手段,你能夠繞過保護dangerouslySetInnerHTML,可是它很是氣餒並常常致使安全漏洞。)
在將來的主要版本中,若是遇到javascript:URL
, React將拋出錯誤。
棄用「工廠」組件
在使用Babel編譯JavaScript類以前變得流行以前,React支持使用render方法返回對象的「工廠」組件:
function FactoryComponent() { return { render() { return <div />; } } }
這種模式使人困惑,由於它看起來太像一個功能組件 - 但它不是一個。(函數組件只會<div />在上面的例子中返回。)
這種模式幾乎從未在野外使用,而且支持它會致使React略大且比必要的慢。所以,咱們在16.9中棄用此模式,並在遇到警告時記錄警告。若是您依賴它,添加FactoryComponent.prototype = React.Component.prototype
能夠做爲一種解決方法。或者,您能夠將其轉換爲類或函數組件。
咱們不但願大多數代碼庫受此影響。
React 16.8引入了一個新的測試實用程序,act()用於幫助您編寫更符合瀏覽器行爲的測試。例如,一次act()獲取批量內的多個狀態更新。這與React在處理真實瀏覽器事件時的工做方式相匹配,並有助於爲未來React將更頻繁地批量更新的組件作好準備。
可是,在16.8中act()僅支持同步功能。有時,您可能在測試中看到過相似的警告但沒法輕鬆修復它:
An update to SomeComponent inside a test was not wrapped in act(...).
在React 16.9中,act()也接受異步函數,你能夠await調用它:
await act(async () => { // ... });
這解決了act()之前沒法使用的其他狀況,例如狀態更新在異步函數內部時。所以,您應該可以當即修復act()測試中的全部剩餘警告。
咱們據說沒有足夠的信息來講明如何編寫測試act()。新的「 測試食譜」指南介紹了常見的場景,以及如何act()幫助您編寫好的測試。這些示例使用vanilla DOM API,但您也可使用React Testing Library來減小樣板代碼。它的許多方法已在act()內部使用。
若是您碰到任何其餘不適合您的狀況,請告知咱們問題跟蹤器act(),咱們會盡力提供幫助。
在React 16.5中,咱們爲DevTools引入了一個新的React Profiler
,它能夠幫助您找到應用程序中的性能瓶頸。在React 16.9中,咱們還添加了一種編程方式來收集所謂的測量<React.Profiler>。咱們預計大多數較小的應用都不會使用它,但在較大的應用中跟蹤性能迴歸可能很方便。
該<Profiler>
如何每每是一個做出反應的應用程序呈現什麼渲染的「成本」的措施。其目的是幫助識別應用程序的某些部分,這些部分很慢而且可能會受益於優化(如memoization)。
<Profiler>能夠在React樹中的任何位置添加A 來測量渲染樹的該部分的成本。它須要兩個道具:一個id(字符串)和一個onRender回調(函數),當樹中的一個組件「提交」更新時,它會調用它。
render( <Profiler id="application" onRender={onRenderCallback}> <App> <Navigation {...props} /> <Main {...props} /> </App> </Profiler> );
要了解更多有關Profiler並傳遞給參數onRender回調,檢查出的Profiler文檔。
注意:
分析會增長一些額外的開銷,所以在生產構建中禁用它。
爲了選擇生產分析,React提供了一個特殊的生產構建,並啓用了分析。閱讀有關如何在fb.me/react-profiling中使用此構建的更多信息。
值得注意的錯誤修正
此版本包含一些其餘顯着的改進:
修復findDOMNode()了在<Suspense>
樹內調用時崩潰的問題。
保留刪除的子樹致使的內存泄漏也已獲得修復。
由setStatein 引發的無限循環useEffect如今記錄錯誤。(這相似於你看,當你調用錯誤setState中componentDidUpdate的一類。)
咱們感謝全部幫助解決這些問題和其餘問題的貢獻者。您能夠在下面找到完整的更改日誌。
路線圖的更新
在2018年11月,咱們發佈了16.x版本的路線圖:
帶有React Hooks的小型16.x版本(過去估計:2019年第一季度)
帶有併發模式的小型16.x版本(過去的估計:2019年第二季度)
帶有Suspense for Data Fetching的未成年人16.x版本(過去估計:2019年中)
這些估計太樂觀了,咱們須要調整它們。
tldr:咱們按時發佈了Hooks,但咱們正在將Concurrent Mode和Suspense for Data Fetching從新組合成一個咱們打算在今年晚些時候發佈的版本。
2月份,咱們發佈了一個穩定的16.8版本,包括React Hooks,一個月後 React Native支持。可是,咱們低估了此版本的後續工做,包括lint規則,開發人員工具,示例和更多文檔。這使時間線改變了幾個月。
如今React Hooks已經推出,並行模式和數據提取的懸念工做正在全面展開。目前正在積極開發的新Facebook網站創建在這些功能之上。使用真實代碼對它們進行測試有助於在影響開源用戶以前發現並解決許多問題。其中一些修復涉及這些功能的內部從新設計,這也致使時間線滑落。
有了這種新的理解,這就是咱們計劃下一步作的事情。
一個發行而不是兩個
Concurrent Mode和Suspense 爲正在積極開發的新Facebook網站提供支持,所以咱們有信心他們在技術上接近穩定狀態。咱們如今也更好地瞭解了它們爲開源採用作好準備以前的具體步驟。
最初咱們認爲咱們會將Concurrent Mode和Suspense for Data Fetching分紅兩個版本。咱們發現這種排序很難解釋,由於這些特徵與咱們最初想到的相關性更大。所以,咱們計劃在單個組合版本中發佈對Concurrent Mode和Suspense for Data Fetching的支持。
咱們不但願再次過分推銷發佈日期。鑑於咱們在生產代碼中依賴於它們,咱們但願今年可以提供16.x版本,併爲其提供選擇支持。
數據提取的更新
雖然React並未就如何獲取數據發表意見,但數據提取的Suspense的第一個版本可能會專一於與固定數據提取庫集成。例如,在Facebook,咱們正在使用與Suspense集成的即將推出的Relay API。咱們將記錄像Apollo這樣的其餘自覺得是的圖書館如何支持相似的整合。
在第一個版本中,咱們不打算關注咱們在早期演示中使用的臨時「觸發HTTP請求」解決方案(也稱爲「React Cache」)。可是,咱們但願咱們和React社區將在首次發佈後的幾個月內探索該空間。
服務器渲染的更新
咱們已經開始研究新的支持Suspense的服務器渲染器,可是咱們不但願它爲初始版本的併發模式作好準備。可是,此版本將提供一個臨時解決方案,容許現有服務器呈現器當即爲Suspense回退發出HTML,而後在客戶端上呈現其真實內容。這是咱們目前在Facebook上使用的解決方案,直到流式渲染器準備就緒。
爲何須要這麼長時間?
咱們已經發布了致使Concurrent Mode穩定的各個部分,包括新的上下文API,延遲加載Suspense和Hooks。咱們也急於釋放其餘缺失的部分,可是大規模地嘗試它們是該過程的重要部分。誠實的回答是,當咱們開始時,它只須要比咱們預期的更多的工做。與往常同樣,咱們感謝您在Twitter和咱們的問題跟蹤器中提出的問題和反饋。
安裝
應對
Npm註冊表中提供了React v16.9.0。
要使用Yarn安裝React 16,請運行:
yarn add react@^16.9.0 react-dom@^16.9.0
要使用npm安裝React 16,請運行:
npm install --save react@^16.9.0 react-dom@^16.9.0
咱們還經過CDN提供了反應的UMD版本:
<script crossorigin src="https://unpkg.com/react@16/um...;></script>
<script crossorigin src="https://unpkg.com/react-dom@1...;></script>
有關詳細的安裝說明,請參閱文檔。
更新日誌
應對
添加<React.Profiler>API以編程方式收集性能測量。(@bvaughn在#15172)
刪除unstable_ConcurrentMode同意unstable_createRoot。(@acdlite在#15532)
反應DOM
棄用UNSAFE_*生命週期方法的舊名稱。(@bvaughn在#15186和@threepointone在#16103)
將javascript:URL 棄用爲常見攻擊面。(@sebmarkbage在#15047)
棄用不常見的「模塊模式」(工廠)組件。(@sebmarkbage在#15145)
添加對disablePictureInPicture屬性的支持<video>。(@eek in #15334)
添加對onLoad事件的支持<embed>。(@cherniavskii在#15614)
useState從DevTools 添加對編輯狀態的支持。(@bvaughn在#14906)
添加對從DevTools切換Suspense的支持。(@gaeon在#15232)
setState從調用時發出警告useEffect,建立循環。(@gaeon在#15180)
修復內存泄漏。(@paulshen in #16115)
修復包含在其中findDOMNode的組件的內部崩潰<Suspense>。(@acdlite在#15312)
修復因刷新太晚而致使的待處理效果。(@acdlite在#15650)
修復警告消息中不正確的參數順序。(@brickspert在#15345)
修復了存在!important樣式時隱藏懸疑後備節點的問題。(@acdlite在#15861和#15882)
略微提升保溼性能。(@bmeurer在#15998)
反應DOM服務器
修復camelCase自定義CSS屬性名稱的錯誤輸出。(@bedakb在#16167)
反應測試實用程序和測試渲染器
添加act(async () => ...)用於測試異步狀態更新。(#14853中的@threepointone)
添加對act不一樣渲染器的嵌套的支持。(@threepointone在#16039和#16042)
若是在act()通話外安排效果,請在嚴格模式下警告。(@threepointone在#15763和#16041)
act從錯誤的渲染器使用時發出警告。(@threepointone在#15756)
編輯這個頁面
歡迎加入咱們的
SegmentFault
前端交流羣~
目前人數太多,只能我邀請入羣了哦~