列出實際項目開發(fā)中的經(jīng)驗、技巧，還有曾經(jīng)年少無知時一起挖過的坑...
歡迎大家來吐槽，推薦開發(fā)經(jīng)驗技巧。
后續(xù)不斷更新...

目錄(原諒簡書中無法使用的目錄跳轉(zhuǎn)吧)

1. Exp1:節(jié)省時間之測試模式
2. Exp2:繼承的實際應(yīng)用

Exp1:節(jié)省時間之測試模式

時間就是金錢
實際項目開發(fā)中，我們需要一整套的開發(fā)測試模式，便于我們開發(fā)，開發(fā)模式/發(fā)布模式僅需要一個開關(guān)來控制，快捷高效。猶如之前做游戲一樣，LOCAL_MODE開啟就變成單機游戲，關(guān)閉就成為網(wǎng)絡(luò)游戲。

下面是我實際開發(fā)中的一部分

// 全局的配置表
var GlobalConfig = {
    DEV_MODE: false,              // true開發(fā)模式 false發(fā)布模式

    SANDBOX_MODE: false,           // 沙盒模式
    
    TEST_MODE: true,               // 測試模式,僅在【開發(fā)模式】下有效
    TEST_VIEW: 'views.TestView',   // 直接跳轉(zhuǎn)的測試界面
    TEST_VIEW_PARAMS: {            // 測試界面的傳入?yún)?shù)【手動模擬】
        id: 100,
    }
};

// 發(fā)布模式下強制關(guān)閉【沙盒模式】
GlobalConfig.SANDBOX_MODE = GlobalConfig.DEV_MODE ? GlobalConfig.SANDBOX_MODE : false

// 發(fā)布模式下強制關(guān)閉【測試模式】
GlobalConfig.TEST_MODE = GlobalConfig.DEV_MODE ? GlobalConfig.TEST_MODE : false

DEBUG_MODE 開發(fā)/發(fā)布

用來標(biāo)志是開發(fā)模式還是發(fā)布模式的開關(guān)

SANDBOX_MODE 沙盒模式

實際項目中需要模擬填充一些數(shù)據(jù)。而這些數(shù)據(jù)在正式發(fā)布或者特定測試時又不需要。
例如：注冊流程，需要注冊手機號、賬號、密碼、姓名、身份證、住址等信息，這時候就可以用到沙盒模式了

需求:

• 每次填寫注冊信息麻煩，我們需要快速的測試整個注冊流程
• 在【開發(fā)模式】下，我們有時候也需要手動填充一些數(shù)據(jù)測試，這時候需要關(guān)閉【沙盒模式】
• 測試數(shù)據(jù)保留，方便我們下次再次使用
• 測試數(shù)據(jù)在【發(fā)布模式】時要關(guān)掉，不能影響上線產(chǎn)品的數(shù)據(jù)

實際項目中,注冊賬號中使用到的沙盒模式

this.state = {
    account: '',
    pwd: '',
    pwdex: '',
};

if (config.SANDBOX_MODE) {
    this.state.account = utils.sandboxAccount()
    this.state.pwd = utils.sandboxPwd()
    this.state.pwdex = this.state.pwd
}

TEST_MODE 快速測試模式

直接跳轉(zhuǎn)到我們需要的界面，快速測試數(shù)據(jù)，而不需要每次都走通整個流程才到測試界面

TEST_MODE: true, // 測試模式,僅在【開發(fā)模式】下有效 
TEST_VIEW: 'views.TestView', // 直接跳轉(zhuǎn)的測試界面 
TEST_VIEW_PARAMS: { // 測試界面的傳入?yún)?shù)【手動模擬】 
    id: 100,
 }

Exp2:繼承的實際應(yīng)用

實際開發(fā)中，會遇到多種界面，非常類似，如我們開發(fā)中的，通過電話號碼查詢、通過郵件查詢、通過QQ號碼查詢，這些界面邏輯非常的相似，查詢開始要轉(zhuǎn)同樣的菊花，查詢結(jié)束要取消菊花，查詢不到提示同樣的信息等等。如果分開寫，不僅邏輯復(fù)雜且不易維護，如果后期增加了N個同樣的界面，維護成本就成倍的提升了。

解決方案:繼承

和組件并不沖突，如都轉(zhuǎn)菊花， 我們可以將菊花放到一個組件中統(tǒng)一維護，但是涉及到搜羅的邏輯，我們只能通過繼承來實現(xiàn)。

基類

export default class SearchBase extends Component {
    constructor(props) {
        super(props);
    }

    componentWillMount() {
        this.onInit()
    }

    onInit() {           //overrite
        // 初始化函數(shù)
    }

    onSendMsgSucceed(data) {
        // do sth.. send msg succeed...
    }

    onSendMsgFailed() {             //overrite
        // do sth.. send msg failed...
    }

    onStartSearch(text) {           // overrite
        // 開始搜索
    }

    render() {
        return (
            <Text>test</Text>
        );
    }
}

派生類

export default class SearchPhone extends SearchBase {
   // 初始化函數(shù)
    onInit() {
        super.onInit()
        // SearchPhone init is here...
    }

    /**
     * overrite
     * 開始查詢數(shù)據(jù)，派生類覆蓋查詢的消息
     * @param text
     */
    onStartSearch(text) {           // overrite
        let is_phone = utils.isPhone(text);
        if (isPhone) {
            ReqSearchInfoByPhone(text,
                (succ)=> {
                    let data = succ[0]
                    this.onSendMsgSucceed(data)
                }, (failed)=> {
                    this.onSendMsgFailed()
                }
            );
        }
    }
}

相同的邏輯，放到基類SearchBase中，需要覆蓋的邏輯，重載基類中的函數(shù)并重新實現(xiàn)

注意:

• 派生類中的constructor中必須實現(xiàn)super(props)，因為es6的class，是先構(gòu)造基類的this，然后是派生類才能使用this
• 正常使用應(yīng)該是

let com = new SearchPhone()
com.init()

這樣能先調(diào)用基類的構(gòu)造函數(shù)，然后是派生類的構(gòu)造函數(shù)，因為組件的調(diào)用是RN來控制的， 我們無法加入一個init函數(shù)，好在實在構(gòu)造函數(shù)之后，且在渲染之前，我們所有將此函數(shù)作為一個初始化函數(shù)觸發(fā)點

componentWillMount() {
    this.onInit()
}