国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

基于Decorator的組件擴展實踐

魏明 / 2428人閱讀

摘要：在業務統一的情況下，僅僅修改組件用于配置的就可以滿足業務需求。避免了復雜的圖表配置，而將圖表進行有效拆分，通過聲明式的標簽進行組合，從而使圖表更具擴展性。而對于顆粒度最細的組件，我們希望它是純粹的，木偶式的組件。

在前端業務開發中，組件化已經成為我們的共識。沉淀和復用組件，是提高開發效率的利器。但在組件復用的過程中，我們往往會遇到這樣的問題，組件相似，卻在結構或交互上有些許差別，需要對組件進行改造方可滿足需求。這個問題之前在 React實踐 - Component Generator 就有所提及。

之初，我們提出了組件配置式。在業務統一的情況下，僅僅修改組件用于配置的props就可以滿足業務需求。但隨著業務發生變化導致組件形態發生變化時，我們就必須不斷增加配置去應對變化，便會出現配置泛濫，而在擴展過程中又必須保證組件向下兼容，只增不減，使組件可維護性的降低。

最近的項目開發中，@JasonHuang 提出了組件組合式開發思想，有效地解決了配置式所存在的一些問題。下面我將詳細闡述其思想與具體實現。

組件再分離

對于組件的 view 層，我們期望組件是沒有冗余的，組件與組件間 view 重疊的部分應當被抽離出來，形成顆粒度更細的組件，使組件組合產生更多的可能。

這種 view 細化的組合式思想早已在我們團隊可視化庫 Recharts 中有所體現。Recharts 避免了復雜的圖表配置，而將圖表進行有效拆分，通過聲明式的標簽進行組合，從而使圖表更具擴展性。

同樣，我們在組件上也希望秉承這種思想，先來看一下在現有業務比較典型的三個公共組件:

這三個組件無論在 UI 還是邏輯上均存在一定共性。在配置式中，我們會將這三個組件通過一個組件的配置變換來實現，但無疑會提高單個組件內部邏輯的復雜性。

再做一次分離！它們可由 SelectInput、SearchInput 與 List 三個顆粒度更細的組件來組合。而對于顆粒度最細的組件，我們希望它是純粹的，木偶式的組件。

例如 SelectInput 組件，組件狀態完全依賴傳入的 props，包括 selectedItem (顯示用戶所選項)、isActive (當前下拉狀態)、onClickHeader (反饋下拉狀態)以及placeholder (下拉框提示)。我們來看一下它的簡要實現:

class SelectInput extends Component {
  static displayName = "SelectInput";
  
  render() {
    const { selectedItem, isActive, onClickHeader, placeholder } = this.props;
    const { text } = selectedItem || {};
    return (
      

        
        
      

    );
  }
}

當組件被再次分離后，我們可以根據業務中的組件形態對其進行任意組合，形成統一層，擺脫在原有組件上擴展的模式，有效提高組件的靈活性。

邏輯再抽象

那么有了 view 細化再重組的公共組件后，是不是就可以愉快地開發了?

是的，但組件層面的抽象不應該只停留在 view 層面，組件中的相同交互邏輯和業務邏輯也應該進行抽象。

ReactEurope 2016 小記 - 上 中提到復用高階函數的思想，編寫 Higher-Order Components (高階組件)來為基礎組件增加新的功能。

Higher-Order Components = Decorators + Components。在我們的組件中，也正是貫穿著這樣函數式的思想，來完成組件邏輯上的抽象，例如:

// 完成SearchInput與List的交互
const SearchDecorator = Wrapper => {
  class WrapperComponent extends Component {
    handleSearch(keyword) {
      this.setState({
        data: this.props.data,
        keyword,
      });
      this.props.onSearch(keyword);
    }

    render() {
      const { data, keyword } = this.state;
      return (
        
      );
    }
  }
  
  return WrapperComponent;
};

// 完成List數據請求
const AsyncSelectDecorator = Wrapper => {
  class WrapperComponent extends Component {
    componentDidMount() {
      const { url } = this.props;
      
      fetch(url)
      .then(response => response.json())
      .then(data => {
        this.setState({
          data,
        });
      });
    }

    render() {
      const { data } = this.state;
      return (
        
      );
    }
  }

  return WrapperComponent;
}

擁有 Decorator 之后，我們就能賦予組件能力了，例如合成 Search 組件:

@SearchDecorator
class Search extends Component {
  render() {
    return (
      
        
        
      
    );
  }
}

那么當我們將邏輯抽象成為多個 Decorator 時，又該如何去組合呢？你是否還記得 React Mixin 的前世今生 中提到的方法？沒錯，就是compose！這里建議讀者 review 這篇文章，順便回顧一下Mixin與高階組件的不同點。

// SelectedItemDecorator為List與SelectInput的交互，讀者可以自行嘗試實現
const FinalSelector = compose(AsyncSelectDecorator, SearchDecorator, SelectedItemDecorator)(Selector);

class SearchSelect extends Component {
  render() {
    return (
      
        
        
        
      
    );
  }
}
小結

在配置式組件內部，組件與組件間以及組件與業務間是緊密關聯的，而對于開發人員而言需要完成的僅僅是配置的工作。而組合式意圖打破這種關聯，尋求單元化，通過顆粒度更細的基礎組件與抽象組件共有交互與業務邏輯的 Decorator，使組件更靈活，更易擴展，也使開發者能夠完成對于基礎組件的自由支配。

雖然組合式確實能解決配置式所存在的一些問題，但多層 Decorator 帶來的多層包裹，會對組件理解和調試造成一定困難，也"不能"使用外部公有的方法。同時組合式所基于的函數式編程的思想能否被整個團隊所接受，也是我們需要考量的問題。

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/80088.html

相關文章

  • 基于Decorator的React高階組件的思路分析與實現

    摘要：在深入技術棧一書中，提到了基于的。書里對基于的沒有給出完整的實現，在這里實現并記錄一下實現的思路。在這里最小的組件就是。對比范式與父組件的范式，如果完全利用來實現的，將操作與分離，也未嘗不可，但卻不優雅。 在深入react 技術棧一書中，提到了基于Decorator的HOC。而不是直接通過父組件來逐層傳遞props，因為當業務邏輯越來越復雜的時候，props的傳遞和維護也將變得困難且冗...

    LinkedME2016 評論0 收藏0

  • 裝飾模式（Decorator Pattern）

    摘要：通常有兩種方式可以實現給一個類或對象增加行為繼承機制，使用繼承機制是給現有類添加功能的一種有效途徑，通過繼承一個現有類可以使得子類在擁有自身方法的同時還擁有父類的方法。 裝飾模式 (Decorator Pattern) 裝飾模式能夠實現動態的為對象添加功能，是從一個對象外部來給對象添加功能。通常有兩種方式可以實現給一個類或對象增加行為： 繼承機制，使用繼承機制是給現有類添加功能的一種...

    gityuan 評論0 收藏0

  • 設計模式之裝飾者模式

    摘要：相關設計模式裝飾者模式和代理模式裝飾者模式關注再一個對象上動態添加方法代理模式關注再對代理對象的控制訪問，可以對客戶隱藏被代理類的信息裝飾著模式和適配器模式都叫包裝模式關于新職責適配器也可以在轉換時增加新的職責，但主要目的不在此。 0x01.定義與類型 定義：裝飾模式指的是在不必改變原類文件和使用繼承的情況下，動態地擴展一個對象的功能。它是通過創建一個包裝對象，也就是裝飾來包裹真實的...

    chuyao 評論0 收藏0

  • Vue with typescript

    摘要：想要使用語法的話，配合，這個插件，體驗更佳，這個插件在語法中實現了。這種方式最接近的單文件組件的寫法，如果一個完善項目從改成，用這種方法很快，只要加上和一些必要的變量類型就好了，然后用包裹就好。不推薦混入用這種方式寫，無法實現多繼承。 最近嘗試了一下 TypeScript，試著把一個 Vue 項目改成了 TypeScript 的，感覺還不錯 目前 Vue 和 TypeScript 的配...

    JerryWangSAP 評論0 收藏0

  • 前端每周清單半年盤點之 Node.js 篇

    摘要：前端每周清單專注前端領域內容，以對外文資料的搜集為主，幫助開發者了解一周前端熱點分為新聞熱點開發教程工程實踐深度閱讀開源項目巔峰人生等欄目。對該漏洞的綜合評級為高危。目前，相關利用方式已經在互聯網上公開，近期出現攻擊嘗試爆發的可能。 前端每周清單專注前端領域內容，以對外文資料的搜集為主，幫助開發者了解一周前端熱點；分為新聞熱點、開發教程、工程實踐、深度閱讀、開源項目、巔峰人生等欄目。歡...

    kid143 評論0 收藏0

發表評論

0條評論

魏明

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<