摘要：高階函數驗證中間件驗證驗證之所以用三種方式一起是因為高階函數在性能調優的時候并不是特別容易。總結高階函數適合用在子控件需要確定權限后渲染中間件適合無狀態頁面中的登錄狀態判斷驗證，使用范圍就比較狹窄了。

最近一直在寫一個React、Redux的前端項目，登錄狀態驗證這一塊還是比較頭疼的。

我的實踐下有三種方式來驗證用戶登錄狀態，目前我選擇用三種方式一起用在項目里面。

Redux高階函數驗證（High-Order Function）

Actions中間件驗證

Component WillMount 驗證

之所以用三種方式一起是因為Redux高階函數在性能調優的時候并不是特別容易。

//把需要登錄狀態驗證的Component傳入到這個高階函數中
export function requireAuthentication(Component) {
    class AuthenticatedComponent extends Component {
        constructor(props) {
            super(props)
        }
        //只在首次Mount時來驗證權限
        componentWillMount() {
            this.checkAuth();
        }
        checkAuth(){
            const {path,isSignIn,dispatch}=this.props;
            if(!isSignIn){
                //沒有登錄
                //記錄當前頁面path
                //跳轉到SignIn Page處理登錄 登錄完成夠會跳回當前頁面
                dispatch(CommonActions.setNextUrl(path))
                browserHistory.push("/sign");
            }
        }
        render() {
            console.log("auth render")
            return (
                

                
                    {this.props.isSignIn == true
                        ? 
                        : null
                    }
                
            )

        }
    }

    const mapStateToProps = (state) => ({
        path:state.routing.locationBeforeTransitions.pathname,
        isSignIn:state.common.isSignIn,
        state:state
    })
    return connect(mapStateToProps)(AuthenticatedComponent);
}

你可以把它像這樣用在router中：

{ path:"courseCate",component:requireAuthentication(CourseCate)}

目前存在的一些問題：

高階函數中傳入的最頂層的Component不能再使用connect

過多的高階函數生命周期的邏輯難以維護、性能隱患

export function checkAuth(nextUrl,nextFn) {
    return (dispatch,getState)=>{
        //檢測用戶登錄情況
        if(!getState().common.isSignIn){
            //沒有登錄 記錄當前path 
            //跳轉到sign page 登錄完成后 跳轉回來
            dispatch(setNextUrl(nextUrl));
            pushUrl("/sign");//封裝了 browserHistory.push(url)
        }else{
            //通過驗證后 執行下一個Fn
            dispatch(nextFn);
        }
    }
}

你可以像這樣用在你的Actions中

export function fetchFoo(url,conf) {

    return (dispatch,getState) => {
        if(shouldFetchFoo(getState())){
            dispatch(requestFetchFoo());
            return fetch(url,conf)
            .then(res=>res.json())
            .then(json=>{
                ...
            })
        }
    }
    
}
export function needFetchFoo(nextUrl,url,conf){
    retrun (dispatch)=>{
        dispatch(checkAuth(nextUrl,fetchFoo(url,conf)))
    }
}

目前存在的一些問題：

雖然可以避免過多的高階函數函數導致頁面性能下降，但是無法很好滿足業務邏輯

驗證如果未通過直接阻斷當前操作

這基本上可以認為是Actions中間驗證的一種變種

export function checkAuthWithoutNextFn(nextUrl) {
    return (dispatch,getState)=>{
        //check if user sign in
        if(!getState().common.isSignIn){
            //if not set the nexturl 
            //and push url to sign page
            dispatch(setNextUrl(nextUrl));
            pushUrl("/sign");
        }
    }
}

你可以像這樣把他用在Component WillMount事件中

    componentWillMount(){
        const {dispatch} = this.props;
        dispatch(CommonActions.checkAuthWithoutNextFn("/coursecate"));
    }

目前存在的一些問題：

權限未得到驗證時，不會阻斷子控件渲染，觸發子控件生命周期中的事件

舉個例子:
比如父控件中componetWillDidMount中調用該方法判斷用戶登錄狀態
fatherComponet.js

    componentWillMount(){
        const {dispatch} = this.props;
        dispatch(CommonActions.checkAuthWithoutNextFn("/coursecate"));
    }

然而子控件componentWillMount中有一個fetch是需要權限驗證（此時父控件中并沒有阻斷子控件渲染，在父控件正在驗證權限的同時，子控件的fetch執行了。高階函數可以阻斷子控件渲染）的。
雖然渲染順序是fatherComponet->childComponet
但是childComponet里的componentWillMount也是觸發了（也就是說，在未驗證登錄情況下就觸發了fetch），可能會造成一些不必要的請求。
我目前的處理方式：在子控件ComponentWillMount的fetch中加入一個shouldFetch()進行請求前判斷。

1.高階函數適合用在：子控件需要確定權限后渲染
2.actions中間件適合：無狀態頁面中的登錄狀態判斷
3.component驗證，使用范圍就比較狹窄了。

大家雨露均沾

以上是我個人目前的一些小見解，歡迎各位指正和補充哈。