1樓：CoyeaH
個人淺見：
元件的出現就是為了解決復用的問題，這樣一來就是可以做到充分的解耦合（當然要看你具體怎麼寫）。
解決耦合和高復用，為了適應更多的環境，就要相應的指定一些props上的規則。我覺得乙個例子是挺不錯的就是antd，可跨專案吧？可以！
當然，容器元件比展示元件的適用度會小。
2樓：
元件的概念還是比較寬的，有些元件依賴性小，可任意使用，這類元件在使用上相對靈活。另有一些元件存在相關關聯，尤其是 UI 元件，常常會以一套的形式出現，這類元件之間的耦合相對較深。
寫前端程式的時候，如果是自製框架，選用適合的單元件組合就好。但是如果使用成品框架，那設計應該盡量按照框架的設計思想來設計，避免過度自定義與框架設計衝突不便後期處理。當然這個度的把握就沒什麼模式了，要開發過程中試水。
最後，元件能否應用於另乙個專案中，取決於元件的靈活程度以及兩個專案間的相似度。比如多數 Form 元件都是可以在多個專案中復用的，但是有一些貼合業務的自定義元件那就只能在業務相似的專案中復用啦
3樓：林沈離
用react、Angular或vue框架。。這些都幫你準備好了，哪用得著自己考慮。
如果是想不用框架寫，參考WebComponent規範。
Google Polymer是前端元件化的未來！那對於現在當下，又該採用什麼技術實現元件化呢？AngularJs可以勝任嗎？
小芋頭君 大家說的很明白了，只說一句 沒事別瞎折騰，元件化的最大目的是可復用性和團隊開發時候的分工。如果你的頁面沒有特別大的需求，別想著折騰這些，先把前端工程化和表層面的模組化和前端團隊的規範化做好再說吧。普通的web頁面元件化後，如果你的復用很少，基本上的後果就是維護成本陡增，關鍵是並沒有特別大的...
未來的前端框架的元件編譯成 Web Components 是否是趨勢？跨框架元件是不是未來的趨勢？
龍騰道默默地 custom elements 有全域性汙染問題，怎麼可能成為載體。web components 又不管 MVVM，怎麼可能取代三大框架。換句話說，如果不是為了 MVVM，又有誰會用三大框架？所以更有可能反過來，三大框架繼續作為載體存在，而它們的每個元件內部都用 web compone...
產品經理 b端業務，想要更好的理解業務邏輯，寫出比較有水平的prd文件，需要懂多少技術知識
業務邏輯理解跟有水平的prd不是一碼事 粗略盤一下，大概需要知道這麼多？mvc mvp mvvm mysql mongoDB kafka redishadoop Spark flink vue node.js React flutterhtml css js TypeScriptsoa DDD 設計...