優維低代碼技術專欄，是一個全新的、技術為主的專欄，由優維技術委員會成員執筆，基于優維7年低代碼技術研發及運維成果，主要介紹低代碼相關的技術原理及架構邏輯，目的是給廣大運維人提供一個技術交流與學習的平台。
優維低代碼實踐連載第12期
《Context / State》
▽
在開發中有一項重要的工作是維護和管理我們的資料，比如頁面需要擷取遠端的資料進行渲染或者聲明變量，然後動态更新資料等，這些都需要我們能提供一套聲明和消費資料的機制。對此，我們平台提供了 Context 和 State 兩種資料的管理方式。
Context 為全局的狀态資料，在一個路由的頁面周期中都有效，作用域為整個路由範圍内，相當于我們的全局變量；而 State 是局部的狀态資料，相當于我們的局部變量，其隻應用于模闆的内部。同時引用的這些狀态資料還能支援實時更新的能力，這對于我們編排來說可謂是如虎添翼。
Context
context 通常聲明在某一個路由下，表示在該路由下可使用的變量，我們來看一下 context 具體使用方式。
1.1 context 定義
上述圖中，我們發現 context 還有一些配置項，分别是 if，onchange，track，和 provider 相關的 transform 和 onReject，我們接下來詳細說明下該配置項的用途。
1.2 配置詳解
Context 級别的配置，我們以 yaml 的配置形式來介紹。
1.2.1 basic settings
if 條件配置
可以配置 if 來按條件決定是否執行對應的 Context
onChange
有時候我們希望聲明一個 Context 變量，但不對它立即指派，而是通過特定事件觸發指派，并且希望能監聽其變更事件。
可以在聲明 Context 時定義 onChange, 然後在特定條件發生時再對其指派，當 Context 發生變化時，onChange 注冊的事件處理器将被調用。圖中的EVENT.detail為該 Context 的值，
track
依賴追蹤，也就是說目前 contextA 下有依賴的其他的contextB，當 ContextB 變化後(通過 context.replace/context.refresh等)， contextA 的值會重新計算。
1.2.2 Provider settings
transform/onReject
當 context 為 provider/contract 類型時，針對該請求的傳回可配置 transform, onReject 和 lazy 項，
transform 顧名思義是對傳回的接口做資料處理用，而 OnReject 則對請求報錯時額外做的特殊處理，正常情況我們一般不會配置 OnReject，因為系統會統一捕獲并顯示錯誤資訊。
lazy
對于 provider 中的 lazy 項，我們稱之為懶加載。預設情況下，我們的請求都會在頁面加載前發起并會阻塞渲染，但有些資料并不着急需要，可能隻需在特定條件下發起請求即可（例如打開抽屜和彈窗）。這時，可以标記為 lazy: true 将它設定為懶加載，該資料将不會預設發送請求，需要在特定條件下主動觸發 context.load /context.refresh 來發起請求。
1.2.3 PATH
PATH 的配置項是給 context 分組用的，當一個路由管理的 context 很多時，為了友善管理和查找，我們可以給每一個 context 進行分類，這樣同一類下的 context 會放在同一目錄下展示。
1.3 context 使用
當我們定義好 context 後，就可以在編排中直接使用了，在使用時需要加上 CTX 的字首，同時我們使用 context 的地方也支援了 track context 的能力，隻要在表達式前面添加一句 "track context" 構件的屬性就能跟随 Context 變化而自動重新計算并指派。
State
State 的能力和 Context 幾乎完全一緻，不同的是，Context 的作用域是整個頁面、是全局的，我們的自定義模闆，同一個模闆在頁面中可能有多個執行個體，如果直接使用 Context，則多個執行個體間的資料會互相影響。另外，使用全局的 Context 也會破壞模闆的封裝，削弱應用的可維護性，并帶來潛在的問題。
是以 State 正是為了解決這個問題，它用于管理自定義模闆内的資料，其作用域是模闆的執行個體，多個模闆執行個體之間的資料互相隔離。同時，在能力上完全與 Context 對等。
State 的定義也和 Context 一緻，它隻能在模闆的頁面中使用，與 Context 不同的是 State 有屬于自己的狀态更新的 action，它與 context 一一對應。