資訊專欄INFORMATION COLUMN
摘要：觀察者模式，一次創建多條通信鏈路，每條鏈路工作時與其他鏈路發生干擾。在目前系統中，只存在兄弟通信和父子通信，不存在跨樹通信，即孩子不能跟叔叔直接通信。模擬操作的方式，歸根到底是把手動測試過程用腳本記錄下來。
作者：BrianLi （部門同事李老師，口頭授權發布內部react布道資料）
無法用語言準確表達思維時，就用公式；一個不行，那就兩個
—— 李老師
本文假設讀者已了解react的基本概念，并有少量react開發實踐。如果沒有，請先閱讀
http://www.ruanyifeng.com/blog/2015/03/react.html
當前業務模塊之間如何通信？備注：微信不支持公式，所以我這邊截圖。
補充一下f表示一次用m生成v的渲染方法
g是界面發生交互時，對m做修改的方法
回調模式：callback
觀察者模式：on / fire (addEventListener / removeEventListener)
偽總線模式：fcContextChange
三種模式沒有本質區別：
回調模式，一次創建一條通信鏈路，此鏈路工作時不與其他鏈路發生干擾。
觀察者模式，一次創建多條通信鏈路，每條鏈路工作時與其他鏈路發生干擾。
偽總線模式，是一種特殊的觀察者模式，信息的發出者是一個固定的模塊。
在目前系統中，只存在兄弟通信和父子通信，不存在跨樹通信，即孩子不能跟叔叔直接通信。如果要跟叔叔通信，必須借助祖先中轉。
現在開始簡化模型：
假設系統中模塊之間的鏈路能雙向通信，這樣可以將有向鏈路換成無向鏈路；
假設任意兩個模塊之間都可以存在鏈路，但只允許存在一條鏈路，這樣之前不同的鏈路類型下降成單條鏈路的一個參數，并且將祖先中轉縮短成直接通信；
把系統中的模塊看作頂點，模塊間通信鏈路看作邊，則系統變成了無向圖。
這是模型簡化后的鏈路數量，而目前我們系統中的鏈路數比這多得多，因為我們允許節點間有多條鏈路，而且鏈路是單向通信的。
我們開發業務時很大一部分工作量就是創建各種通信鏈路，隨著系統復雜性不斷增加，圖越來越復雜，代碼邏輯就沒人能看懂了，因為數據在系統中的流動是沒有規律的。
React基本原則2：在React中，數據流是單向的。數據總是自頂而下流動，內部不允許出現反向數據流。React簡化通信的方法相當粗暴，既然管理不好通信，那么干脆禁止通信。
如何用React滿足我們的通信需求？React的做法是：
把整個應用抽象成一個數據集;
每個子模塊使用數據集的一部分做渲染，涉及渲染的數據通過props向下傳遞；
每個子模塊都可以直接修改最頂層的數據集。
現在，系統中通信鏈路條數變成了n，系統復雜度完全在我們掌控之中。當然這樣做也是有弊端的，所有數據放在一個model中，這個model必然很龐大，維護起來需要一定技巧，相應地出現了flux和redux等框架專門用于管理model，目前我們沒有引入，準備使用ER.model，加強命名規范，來臨時解決這一問題。
最關鍵，上圖綠色鏈路的創建過程是半自動化的，只需要把修改model的回調函數mode.dispatch通過props一層層傳遞下去。當然，綠色鏈路的創建可以利用react.context做成全自動，但react官方對context的使用有疑慮，并且API在將來可能會修改，所以暫時沒有引入。
當前我們如何測試ui和業務模塊？Note
Context is an advanced and experimental feature. The API is likely to change in future releases.
Most applications will never need to use context. Especially if you are just getting started with React, you likely do not want to use context. Using context will make your code harder to understand because it makes the data flow less clear. It is similar to using global variables to pass state through your application.
If you have to use context, use it sparingly.
Regardless of whether you"re building an application or a library, try to isolate your use of context to a small area and avoid using the context API directly when possible so that it"s easier to upgrade when the API changes.
答案是測試基本靠手。怎么測試交互？目前有基于web driver的OneUX SDK方案。這個方案用腳本模仿了鼠標鍵盤操作，允許我們實現自動化測試。
但問題不在這里，而是工作量的問題。模擬操作的方式，歸根到底是QA把手動測試過程用腳本記錄下來。如果測試一次性通過，手動測試和寫腳本的工作量是一致的。
在React中，自動化測試變得非常簡單。還記得React基本原則1么？props + state是渲染界面view的唯一依據。因此，用戶在頁面的交互行為，最終都轉化成props或state的變化。
個人博客http://tangguangyao.github.io/
微信公眾號文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/78863.html
摘要：官方說法注本人英語二十六級是和用來創建用戶界面的庫。很多人將認為是中的。怎么說呢現在的自己就是個跟風狗啊，什么流行先學習了再說，再看看能不能應用在具體項目上。暫時先停下的學習，坐等。不過學習的腳步還是跟不上潮流的發展速度啊。 Why React? 官方說法 注：本人英語二十六級 React是Facebook和Instagram用來創建用戶界面的JavaScript庫。很多...
摘要：如何修復既然是不需要渲染，那就要阻止它的渲染。我個人覺得，在實際中，用跟兩個工具已經可以很好幫我們判斷哪部分不需要重新渲染，幫助我們做出優化。 背景 上一篇文章的結尾http://imweb.io/topic/5985cc4...我們說到，也許，不是所有的節點都需要重新渲染，對于那些不需要渲染的節點，我們如何找到它們并做優化呢？ 本篇文章來具體解答這個問題。 應用分析 首先，先看這個應...
摘要：三性能優化處理做工具類的項目，性能是非常大的挑戰，我總結了以下幾個常見的性能優化點數據緩存。防抖，節流，事件委托內存釋放。 內容大綱： 1、功能介紹 2、技術架構 3、性能優化 4、細節分享 5、開源說明 一、項目功能介紹 很久沒寫過技術類的文章了，這次給大家分享一個近期的項目，采用react+mobx+jquery構建的大型工具類項目。查看項目網址。 如果用過易企秀，maka或者...
摘要：三性能優化處理做工具類的項目，性能是非常大的挑戰，我總結了以下幾個常見的性能優化點數據緩存。防抖，節流，事件委托內存釋放。 內容大綱： 1、功能介紹 2、技術架構 3、性能優化 4、細節分享 5、開源說明 一、項目功能介紹 很久沒寫過技術類的文章了，這次給大家分享一個近期的項目，采用react+mobx+jquery構建的大型工具類項目。查看項目網址。 如果用過易企秀，maka或者...
閱讀 2234·2021-11-17 09:33
閱讀 2774·2021-11-12 10:36
閱讀 3396·2021-09-27 13:47
閱讀 884·2021-09-22 15:10
閱讀 3485·2021-09-09 11:51
閱讀 1392·2021-08-25 09:38
閱讀 2757·2019-08-30 15:55
閱讀 2608·2019-08-30 15:53
