在前端業務開發中，元件化已經成為我們的共識。沉澱和復用元件，是提高開發效率的利器。但在元件復用的過程中，我們往往會遇到這樣的問題，元件相似，卻在結構或互動上有些許差別，需要對元件進行改造方可滿足需求。這個問題之前在 react實踐 - component generator 就有所提及。
之初，我們提出了元件配置式。在業務統一的情況下，僅僅修改元件用於配置的props就可以滿足業務需求。但隨著業務發生變化導致元件形態發生變化時，我們就必須不斷增加配置去應對變化，便會出現配置氾濫，而在擴充套件過程中又必須保證元件向下相容，只增不減，使元件可維護性的降低。
最近的專案開發中，@jasonhuang 提出了元件組合式開發思想，有效地解決了配置式所存在的一些問題。下面我將詳細闡述其思想與具體實現。
對於元件的 view 層，我們期望元件是沒有冗餘的，元件與元件間 view 重疊的部分應當被抽離出來，形成顆粒度更細的元件，使元件組合產生更多的可能。
這種 view 細化的組合式思想早已在我們團隊視覺化庫 recharts 中有所體現。recharts 避免了複雜的圖表配置，而將圖表進行有效拆分，通過宣告式的標籤進行組合，從而使圖表更具擴充套件性。
同樣，我們在元件上也希望秉承這種思想，先來看一下在現有業務比較典型的三個公共元件:
這三個元件無論在 ui 還是邏輯上均存在一定共性。在配置式中，我們會將這三個元件通過乙個元件的配置變換來實現，但無疑會提高單個元件內部邏輯的複雜性。
再做一次分離！它們可由 selectinput、searchinput 與 list 三個顆粒度更細的元件來組合。而對於顆粒度最細的元件，我們希望它是純粹的，木偶式的元件。
例如 selectinput 元件，元件狀態完全依賴傳入的 props，包括 selecteditem (顯示使用者所選項)、isactive (當前下拉狀態)、onclickheader (反饋下拉狀態)以及placeholder (下拉框提示)。我們來看一下它的簡要實現:
class selectinput extends component = this.props;
const = selecteditem || {};
return (
);}}
那麼有了 view 細化再重組的公共元件後，是不是就可以愉快地開發了?
是的，但元件層面的抽象不應該只停留在 view 層面，元件中的相同互動邏輯和業務邏輯也應該進行抽象。
reacteurope 2016 小記 - 上 中提到復用高階函式的思想，編寫 higher-order components (高階元件)來為基礎元件增加新的功能。
higher-order components = decorators + components。在我們的元件中，也正是貫穿著這樣函式式的思想，來完成元件邏輯上的抽象，例如:
// 完成searchinput與list的互動
handlesearch(keyword) );
this.props.onsearch(keyword);
}render() = this.state;
return (
data=
keyword=
onsearch=
/>);
}}
};// 完成list資料請求
componentdidmount() = this.props;
fetch(url)
.then(response => response.json())
.then(data => );
});}
render() = this.state;
return (
data=
/>);}}}
@searchdecorator
class search extends component
}
// selecteditemdecorator為list與selectinput的互動，讀者可以自行嘗試實現
在配置式元件內部，元件與元件間以及元件與業務間是緊密關聯的，而對於開發人員而言需要完成的僅僅是配置的工作。而組合式意圖打破這種關聯，尋求單元化，通過顆粒度更細的基礎元件與抽象元件共有互動與業務邏輯的 decorator，使元件更靈活，更易擴充套件，也使開發者能夠完成對於基礎元件的自由支配。
雖然組合式確實能解決配置式所存在的一些問題，但多層 decorator 帶來的多層包裹，會對元件理解和除錯造成一定困難，也"不能"使用外部公有的方法。同時組合式所基於的函式式程式設計的思想能否被整個團隊所接受，也是我們需要考量的問題。
Easyui 基於kindeditor的擴充套件
原始碼 author 夏悸 easyui kindeditor的簡單擴充套件.有了這個之後,你就可以像使用easyui元件的方式使用kindeditor了 前提是你需要匯入kindeditor的核心js和相關樣式.本外掛程式也需要在easyui.min和kindeditor之後匯入.呵呵.沒做深入擴...
基於元件的開發
一直以為元件是個神秘的東西,也就一直沒有勇氣去實踐他,後來在聽msdn講座時,那個講師舉了個很簡單的例子 元件就是把功能分離出來,生成dll,恍然大悟,原來元件這麼簡單啊.看了ted faison的visual c 基於元件的開發後,覺得元件開發並沒有他說的那麼簡單,大概是那講師為了讓我們對元件感興...
將基於Nullable的型別轉換實現在擴充套件方法中
從上面的介紹我們可以得出這樣的結論 如果型別t1和t2能夠相互相容，我們可以借助convert將t1型別物件轉換成t2型別，然後通過顯式型別轉換進一步轉換成nullable。我們可以通過這兩個步驟實現針對於nullable型別的轉換。為了操作方便，我將此轉換邏輯寫在針對iconvertible介面的...