【譯】React團隊的技術準則

本文翻譯自React團隊核心成員Dan Abramov的技術博客。地址：overreacted.io/what-are-th…

本文首發於公衆號：符合預期的CoyPan

我React團隊工做的這段時間，很幸運可以看見 Jordan、Sebastian、Sophie 和其餘團隊成員是如何解決問題的。在本文中，我會把從他們身上學到的，濃縮爲一篇較高層次的技術準則。這些準則未必詳細。它們都是我對React團隊的觀察和整理 —— 其餘團隊成員或許有其餘的觀點。

UI優先於API

當咱們把抽象概念大規模用於實踐時，不免會有怪異之處。這些怪異之處是如何在用戶界面上呈現的呢？你能看出一個應用中包含了哪些特定的抽象概念麼？

抽象概念對用戶體驗有直接的影響 —— 它能創造好的、延續性的的體驗或者限制某些東西。這也是爲何咱們在設計API時，並不會從抽象自己開始。相反地，咱們會從用戶體驗開始，而後再回到抽象概念。

有時候當咱們回到抽象概念時，會發現必須更改整個方法，才能達到正確的用戶體驗。若是咱們先從API下手，就沒法察覺到這點。因此，咱們將UI放在API以前考慮。

吸取複雜性

簡化React內部的實現並非咱們的目標。若是產品開發者可使用React寫出更易於理解、易於修改的代碼，咱們樂於把React的內部實現變得複雜。

咱們想把產品的開發變得更加職責分明，易於合做。這意味着咱們必須把負責的部分封裝在React的內部。React不能被切分爲小規模、耦合鬆散的模塊，由於這樣便沒法工做。React的使命是成爲協調者的角色。

經過提高抽象層級，使得產品開發者更加有力。產品開發會從React的可預測的完備系統中受益。這意味着咱們推出的每個新功能，都必須兼容已經存在的功能。設計和實現React的新功能十分困難。這也是咱們核心功能並無收到太多開源貢獻的緣由。

咱們吸取了複雜的部分，防止他們污染產品的代碼。

從Hacks到Idioms

每個Api都有一些侷限性。有時，這些限制會妨礙咱們打造良好的使用者體驗。爲此，咱們提供了一些後路（escape hatches）以供須要時使用。

Hacks並非長久之計，由於他們很脆弱。開發者必須決定他們是否維護，支持這些Hack，或者移除hack而犧牲用戶體驗。一般大多數人會犧牲用戶體驗，否則這些hack也會有可能阻礙用戶的優化。

咱們須要讓產品開發者使用這個後路，並觀察在他們實踐中都是如何使用的。咱們的目標是提供這類實現一個經常使用的解決方法（idiomatic solution），目的是達成更好的用戶體驗。有時候，一個解決方案，會花費咱們數年的時間。咱們更傾向於有彈性的hack來確立完整的習慣用法（a poor idiom）。

實現局部開發

你沒法在代碼編輯器作太多的事情。你能夠增長几行，移除幾行。或者複製粘貼。但許多抽象概念讓這些基本操做變得困難。

好比，MVC框架讓刪除一些render的操做變得不可靠。這是由於及即便你刪除了childern的方法，parent仍有可能執行它。相比之下，React的優點在於：你一般能安全的刪除某些render tree內的代碼。

在設計API時，咱們會假設使用它的人只熟悉他們會用到的局部代碼的相關知識。若是預期發生的影響只發生在這局部的代碼中，咱們將會避免意料以外的結果。例如，咱們一般假設新增代碼時安全的。在移除和修改代碼時，應該清楚指出這些改動會連帶影響、應該被考慮到的部分。咱們不該該假設改動單一文件須要對整個代碼都瞭解。

若是某一項改動不安全，咱們但願開發者可以儘早發現這個改動所帶來的的影響。雖然可使用警告、類型檢查和開發者工具來幫忙，但它們都受限於API的設計。若是API不夠局部性，局部開發就不可能實現。例如，findDOMNode就不是一個好的API，由於它須要全面的瞭解。

漸進的複雜度

有些框架會選擇在開發的路上分出岔路，提供兩種路線：簡單的方法或強大、完整的方法。簡單的方法容易學習，但你終究會走到他的極限。這個時候，你必須推倒重來，從新使用另一套方法來實現。

咱們認爲實現一個複雜的東西，和實現一個簡單的東西，在結構上沒有太大的差異。咱們並不會簡單的狀態提供簡單的寫法，由於這樣會使開發中出現岔路。若是咱們認爲開發者在開發過程當中想要完整的開發工具，咱們願意犧牲低門檻來達成這件事。

有時，【簡單】和【強大】表明兩種不一樣的框架，那麼你扔須要換框架重寫，最好能避免這種事。以React爲例，增長服務端的render這類的優化會須要付出額外的努力，但你不須要徹底的重寫。

控制損害

從上到下的解決方式很重要，例如代碼評估。而後長時間下來，咱們的標準會降低，功能會在dead line前完成，也有可能不繼續維護產品。咱們沒法期待全部人都遵照規則，身爲協調者的React必須控制損害。

若是有些UI相關的代碼很慢，咱們須要想盡一切辦法，避免它拖慢載入時間，避免它影響其餘的UI表現。最理想的情況是，開發者只會爲了他們使用到的功能付出開發成本，而產品使用者只須要載入他們會用到的UI。Concurrent Mode ，包括 Time Slicing 和 Selective Hydration ，能夠以不一樣的方式達到理想狀態。

因爲代碼庫自己的性能相對穩定，而應用的代碼沒有底線。所以咱們傾向於在應用代碼中去控制損害，而不是去修正代碼庫內的代碼。

相信理論

有時咱們會知道某些作法是死路一條。也許它如今能夠運做，但能夠想象它的侷限。本質上沒法依靠它來實現想要的用戶體驗。一旦有機會，咱們會馬上從這種狀況中抽身。

咱們不想卡在這裏。若是某種作法在理論上更站得住腳，就算畫上好幾年，咱們也願意在上面投入精力。在達成目標的過程當中，會遇到許多障礙和務實的妥協。但咱們詳細，若持續的客服這些困難，理論終究會獲勝。

大家團隊的準則是什麼

以上是我觀察到的React團隊在工做時的基本原則，但我可能漏了不少。我也還沒提到React如何推出API，團隊如何溝通將來的改動方向等等。或許下次能夠再來談談這些。

大家團隊有什麼準則呢？我洗耳恭聽。

原文地址：overreacted.io/what-are-th…