星級評價組件--引起對React組件的思考

機緣巧合之下，我在接到我司產品星級評價需求的前一天，看到了蝸牛老溼的《★tiny-rate 東半球最小的評級組件☆》，在大佬的啓發下我就十分順手的擼了一個移動端用的星級評價組件。

本篇會涉及的內容有：

• 評價組件的實現
• React組件開發淺談
• 小結&組件源碼(不涉及業務)

星星評價組件的實現

組件的實現十分簡單，基本都是參照tiny-rate的寫法，就是在每顆星星的處理上有點區別：

星星填充的寫法與tiny-rate相似，也是兩層元素的疊加來模擬星星填充的效果，與之不一樣的是我給每顆星星(item)上都添加了點擊事件，爲了兼容咱們在移動端的使用。點擊每顆星星時，獲取其序號，經過css3d的calc來計算出應該變化的寬度，從而達成星星填充的效果。

另外，因爲☆與★在不一樣的手機上顯示的效果可能不盡相同，但由於組件設計模式是疊加，因此咱們能夠將其替換成圖片或是css畫成的符號，以保證各端展現的統一。

最終的效果是這樣滴--

React組件開發淺談

其實本次主要想記錄的內容是我的對React公用組件開發的一些見解--

明確組件功能

以此次的評價組件爲例，在開發的是應該專一於評分的功能&顯示，其餘的需求（例如GIF中點擊星級以後展現的文字說明）或附屬功能都不該該寫到組件內，形成組件與弱相關業務的耦合，這樣才能爲下次在其它情景中使用組件提供便利。

定義默認參數

做爲一個公用的組件，對外暴露的Props是必不可少的，可是假若咱們在引用時，沒有了解清楚必須的Props有哪些時，很容易會形成參數的缺失或錯誤。這種時候若是組件內沒有定義相關的默認參數的話，會致使組件無法正常掛載或者是遍地紅字。

以上述評級組件爲例↓↓

// 在組件頭部就應該定義支撐組件正常運行的Props參數
static defaultProps = {
    canClick: true, // 能否點擊
    rateNum: 5, // 星星個數
    handleSelectRate: null, // 選中星星後的回調
    rateValue: 0 // 選中星星的個數
}
複製代碼

留意組件拓展

咱們的項目確定是不斷在迭代的，因此咱們在設計組件的時候也應該考慮到其靈活性，面對可能出現的需求迭代，應保留相應的配置空間。

如圖中的width計算，在this.state.rateValue沒有被賦值的狀況下，咱們會使用this.props.rateValue中的值來進行展現，這樣就爲咱們的組件拓展出展現功能，不只是在這個頁面負責評分的選擇，還能夠在其餘地方負責評分的顯示。另外，組件的各類樣式也應該是可拓展的方面之一。

須要暴露的API

做爲一個非UI組件，天然是有其須要承擔的功能性職責，這種時候就須要爲其擬定相應的方法，有些方法是組件內部私有的，而有一些則應該暴露出來，讓父級可以順利調用。以評級組件爲例，做爲父組件，在使用該評級組件是最關心的是什麼？沒錯，就是用戶是否點擊了你，而且用戶點擊了什麼評級。這就很明瞭了，咱們在編寫組件時，應該在星星的點擊事件上爲父組件保留點擊成功的響應。

handleSelectRate(value) {
    if (!this.props.canClick) {
        return
    }
    this.setState({
        rateValue: value
    })
    // 點擊成功後調用父組件傳入的方法
    this.props.handleSelectRate && this.props.handleSelectRate(value)
}
複製代碼

小結&組件源碼(不涉及業務)

這些也不是啥乾貨，只是在平時工做開發中總結的一些東西，但願大大們輕拍。不管是用什麼框架，組件應該都是繞不開的話題，若是能養成良好的組件開發思惟，相信能讓咱們的開發效率獲得提高，同時也能爲其餘同事提供便利。

源碼環節--Github傳送門

後話--爲啥你敢把在用的組件源碼直接丟出來？？由於...它真的就只能用來點擊評分...