建站
咨詢
售后
建站咨詢
新聞中心
我React團隊工作的這段時間，很幸運能夠看見 Jordan、Sebastian、Sophie 和其他團隊成員是如何解決問題的。在本文中，我會把從他們身上學(xué)到的，濃縮為一篇較高層次的技術(shù)準則。這些準則未必詳細。它們都是我對React團隊的觀察和整理 —— 其他團隊成員或許有其他的觀點。
成都創(chuàng)新互聯(lián)公司專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于做網(wǎng)站、成都網(wǎng)站建設(shè)、樂亭網(wǎng)絡(luò)推廣、微信平臺小程序開發(fā)、樂亭網(wǎng)絡(luò)營銷、樂亭企業(yè)策劃、樂亭品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎；成都創(chuàng)新互聯(lián)公司為所有大學(xué)生創(chuàng)業(yè)者提供樂亭建站搭建服務(wù)，24小時服務(wù)熱線：13518219792，官方網(wǎng)址：www.cdcxhl.com
UI優(yōu)先于API
當我們把抽象概念大規(guī)模用于實踐時，難免會有怪異之處。這些怪異之處是如何在用戶界面上呈現(xiàn)的呢?你能看出一個應(yīng)用中包含了哪些特定的抽象概念么?
抽象概念對用戶體驗有直接的影響 —— 它能創(chuàng)造好的、延續(xù)性的的體驗或者限制某些東西。這也是為什么我們在設(shè)計API時，并不會從抽象本身開始。相反地，我們會從用戶體驗開始，然后再回到抽象概念。
有時候當我們回到抽象概念時，會發(fā)現(xiàn)必須更改整個方法，才能達到正確的用戶體驗。如果我們先從API下手，就無法察覺到這點。所以，我們將UI放在API之前考慮。
吸收復(fù)雜性
簡化React內(nèi)部的實現(xiàn)并不是我們的目標。如果產(chǎn)品開發(fā)者可以使用React寫出更易于理解、易于修改的代碼，我們樂于把React的內(nèi)部實現(xiàn)變得復(fù)雜。
我們想把產(chǎn)品的開發(fā)變得更加職責(zé)分明，易于合作。這意味著我們必須把負責(zé)的部分封裝在React的內(nèi)部。React不能被切分為小規(guī)模、耦合松散的模塊，因為這樣便無法工作。React的使命是成為協(xié)調(diào)者的角色。
通過提升抽象層級，使得產(chǎn)品開發(fā)者更加有力。產(chǎn)品開發(fā)會從React的可預(yù)測的完備系統(tǒng)中受益。這意味著我們推出的每一個新功能，都必須兼容已經(jīng)存在的功能。設(shè)計和實現(xiàn)React的新功能十分困難。這也是我們核心功能并沒有收到太多開源貢獻的原因。
我們吸收了復(fù)雜的部分，防止他們污染產(chǎn)品的代碼。
從Hacks到Idioms
每一個Api都有一些局限性。有時，這些限制會妨礙我們打造良好的使用者體驗。為此，我們提供了一些后路(escape hatches)以供需要時使用。
Hacks并不是長久之計，因為他們很脆弱。開發(fā)者必須決定他們是否維護，支持這些Hack，或者移除hack而犧牲用戶體驗。通常大多數(shù)人會犧牲用戶體驗，不然這些hack也會有可能阻礙用戶的優(yōu)化。
我們需要讓產(chǎn)品開發(fā)者使用這個后路，并觀察在他們實踐中都是如何使用的。我們的目標是提供這類實現(xiàn)一個常用的解決方法(idiomatic solution)，目的是達成更好的用戶體驗。有時候，一個解決方案，會花費我們數(shù)年的時間。我們更傾向于有彈性的hack來確立完整的習(xí)慣用法(a poor idiom)。
實現(xiàn)局部開發(fā)
你無法在代碼編輯器做太多的事情。你可以增加幾行，移除幾行。或者復(fù)制粘貼。但許多抽象概念讓這些基本操作變得困難。
比如，MVC框架讓刪除一些render的操作變得不可靠。這是因為及即使你刪除了childern的方法，parent仍有可能執(zhí)行它。相比之下，React的優(yōu)勢在于：你通常能安全的刪除某些render tree內(nèi)的代碼。
在設(shè)計API時，我們會假設(shè)使用它的人只熟悉他們會用到的局部代碼的相關(guān)知識。如果預(yù)期發(fā)生的影響只發(fā)生在這局部的代碼中，我們將會避免意料之外的結(jié)果。例如，我們通常假設(shè)新增代碼時安全的。在移除和修改代碼時，應(yīng)該清楚指出這些改動會連帶影響、應(yīng)該被考慮到的部分。我們不應(yīng)該假設(shè)改動單一文件需要對整個代碼都了解。
如果某一項改動不安全，我們希望開發(fā)者能夠盡早發(fā)現(xiàn)這個改動所帶來的的影響。雖然可以使用警告、類型檢查和開發(fā)者工具來幫忙，但它們都受限于API的設(shè)計。如果API不夠局部性，局部開發(fā)就不可能實現(xiàn)。例如，findDOMNode就不是一個好的API，因為它需要全面的了解。
漸進的復(fù)雜度
有些框架會選擇在開發(fā)的路上分出岔路，提供兩種路線：簡單的方法或強大、完整的方法。簡單的方法容易學(xué)習(xí)，但你終究會走到他的極限。這個時候，你必須推倒重來，重新使用另外一套方法來實現(xiàn)。
我們認為實現(xiàn)一個復(fù)雜的東西，和實現(xiàn)一個簡單的東西，在結(jié)構(gòu)上沒有太大的差別。我們并不會簡單的狀態(tài)提供簡單的寫法，因為這樣會使開發(fā)中出現(xiàn)岔路。如果我們認為開發(fā)者在開發(fā)過程中想要完整的開發(fā)工具，我們愿意犧牲低門檻來達成這件事。
有時，【簡單】和【強大】代表兩種不同的框架，那么你扔需要換框架重寫，最好能避免這種事。以React為例，增加服務(wù)端的render這類的優(yōu)化會需要付出額外的努力，但你不需要完全的重寫。
控制損害
從上到下的解決方式很重要，例如代碼評估。然后長時間下來，我們的標準會下降，功能會在dead line前完成，也有可能不繼續(xù)維護產(chǎn)品。我們無法期待所有人都遵守規(guī)則，身為協(xié)調(diào)者的React必須控制損害。
如果有些UI相關(guān)的代碼很慢，我們需要想盡一切辦法，避免它拖慢載入時間，避免它影響其他的UI表現(xiàn)。最理想的狀況是，開發(fā)者只會為了他們使用到的功能付出開發(fā)成本，而產(chǎn)品使用者只需要載入他們會用到的UI。Concurrent Mode ，包括 Time Slicing 和 Selective Hydration ，可以以不同的方式達到理想狀態(tài)。
由于代碼庫本身的性能相對穩(wěn)定，而應(yīng)用的代碼沒有底線。因此我們傾向于在應(yīng)用代碼中去控制損害，而不是去修正代碼庫內(nèi)的代碼。
相信理論
有時我們會知道某些做法是死路一條。也許它現(xiàn)在可以運作，但可以想象它的局限。本質(zhì)上無法依靠它來實現(xiàn)想要的用戶體驗。一旦有機會，我們會立刻從這種情況中抽身。
我們不想卡在這里。如果某種做法在理論上更站得住腳，就算畫上好幾年，我們也愿意在上面投入精力。在達成目標的過程中，會遇到許多障礙和務(wù)實的妥協(xié)。但我們詳細，若持續(xù)的客服這些困難，理論終究會獲勝。
你們團隊的準則是什么
以上是我觀察到的React團隊在工作時的基本原則，但我可能漏了很多。我也還沒提到React如何推出API，團隊如何溝通未來的改動方向等等?；蛟S下次可以再來談?wù)勥@些。
你們團隊有什么準則呢?我洗耳恭聽。
網(wǎng)頁名稱：React團隊的技術(shù)準則
瀏覽地址：http://www.dlmjj.cn/article/cogdjcg.html
