從redux的state中讀取使用者token。
由於這個元件需要讀取存放在redux state中的使用者token，並且包含非同步請求，將它的狀態放入redux中管理，並且使用redux-saga處理非同步請求是非常合適的。
但是在元件的復用性上，我們遇到乙個難題，由於redux本身並不提供模組化功能，我們想要復用使用了redux/redux-saga的元件時：
我們需要為這個元件註冊乙個全域性不衝突的reducerkey。
我們需要修改元件所關注的action型別，因為全域性會有多個元件例項，如果action型別重複，會引起錯誤的元件狀態改變。
元件被解除安裝後，reducer繼續存在，會輕微的損失一些執行效能。
針對這種情形，我們開發了redux-arena
。redux-arena會將redux/redux-saga的**與react元件匯出成乙個react高階元件以供復用：
在高階元件被掛載（mount）時，會自動初始化redux-saga的任務，初始化元件的reducer並在redux維護的state上註冊自己的節點。
在高階元件被解除安裝（unmout）時，會自動取消redux-saga的任務，銷毀元件的reducer並從redux維護的state上刪除自己的節點。
提供元件通道機制，元件傳送的action預設只能被元件自己的reducer接收。也可以通過配置放棄通道，接收全域性的action。
提供vreducerkey機制，redux中如果元件間想共享state資訊，需要知道知道真實的節點名稱，在可復用的redux元件中很容易引發衝突，redux-arena提供vreducerkey機制保證了state節點真實名稱永遠不會衝突。vreducerkey在同名時，下層元件會覆蓋掉上層元件的vreducerkey資訊。
提供單向的（類似flux的 one-way data flow）元件狀態和actions的共享方案，下層元件可以通過vreducerkey獲取上層元件的state和actions。
與redux-saga深度整合，在redux-saga中也可以選擇只傳送和接收元件自己的action。
我們將每乙個匯出的redux/react繫結的高階元件稱為scene。首先我們要為scene構造actions和reducer，然後使用bundletocomponent，匯出高階元件。
import from
"redux-arena/helper";
import * as actions from
"./actions";
import state from
"./actions";
import reducer from
"./reducer";
import componenta from
"./componenta";
export
default bundletocomponent();
複製**
現在我們匯出的這個元件，就可以和普通的元件一樣直接在react中使用了。
需要注意的是，redux-arena增強了redux的store，需要使用createarenastore建立store：
import react from
"react";
import reactdom from
"react-dom";
import from
"react-redux";
import from
"redux-arena";
import componenta from
"./componenta";//上面匯出的高階元件
const store = createarenastore();
reactdom.render(
store=>
provider>,);
複製**
非常的簡單。
每個scene預設只會接受自己所傳送的action，其他scene或者原生redux繫結的action，將會被忽略。
舉個例子：
import from
"redux-arena/helper";
import * as actions from
"./actions";
import reducer from
"./reducer";
import componenta from
"./componenta";
export
const componenta1 = bundletocomponent();
export
const componenta2 = bundletocomponent();
複製**
componenta1和componenta2的****都是相同的，但是他們的reducer只會接收自己的scene內部傳送的action，其他元件傳送的action即使type相同，也會被忽略。
原生的redux中，如果要實現state的共享，需要為元件註冊乙個全域性唯一的reducerkey，然後使用mapstatetoprops方法，將對應state傳入props。
redux-arena使用了vitural reducerkey（vreducerkey），vreducerkey不要求全域性唯一，當子元件的vreducerkey與父元件的vreducerkey相同時，子元件的vreducerkey會覆蓋掉父元件的vreducerkey的資訊。
為scene指定vreducerkey:
import from
"redux-arena/helper";
import * as actions from
"./actions";
import reducer from
"./reducer";
import componenta from
"./componenta";
export
default bundletocomponent(
});複製**
和mapstatetoprops相似，子元件使用propspicker取出所需要的state和actions：
import from
"redux-arena/helper";
import state from
"./state";
import actions from
"./actions";
import componentachild from
"./componentachild";
export
default bundletocomponent()=>()
});複製**
這樣，我們就實現了元件間的state與actions的共享。
需要注意的是，這種共享模式類似flux的one-way data flow，傳遞方向是單向的，反向的資訊傳遞不能使用state，只能使用action。
如果是兄弟元件間的state共享，需要在這些兄弟元件間的某乙個父元件上增加乙個資料層，使用這個統一的父元件資料層共享狀態。
redux-arena提供了一系列的redux-saga方法實現通訊的隔離，使在redux-saga中可以只接收當前scene所派發的action。
使用setscenestate，可以方便的設定當前scene的state。
import from
"redux-arena/sagaops";
function * dosomthing())
}export
function* saga ()
複製**
，具體使用可以參考專案目錄下的example，使用文件陸續補完中。
利用Map解決複雜業務
遍歷出題庫表的題庫名稱和題庫id，根據題目id即questionbankid獲取 分組，即該題庫題目總數，該題庫題目正確數，該題庫已回答題目數。sqltemplate id countanswerdquestion select question bank id select count 1 fro...
專案總結 複雜業務場景的設計與實現
我理解的複雜業務場景，指的是處理鏈路長 乙個完整流程需要多個節點處理 鏈路中某個節點的分支情況多 同一節點下根據不同業務型別有不同的處理邏輯 資料結構繁多且複雜 資料流入時結構越複雜，則說明處理內容增加，業務場景更為複雜 對於複雜的業務場景，建議可以從下面幾個方面參看處理 1.將處理鏈路分模組進行處...
複雜業務邏輯下的合理遍歷
我們在前端介面進行任務手動分配，要求將多條錄音隨機分配給多個質檢員。指定每個質檢員的錄音個數。1 錄音map key id,value time 2 質檢員id list 3 質檢員任務list number 4 需要質檢的錄音數量 1 將所有工單按照指定的分配數量分配給相應的質檢員 param w...