AngularJs 1.5-基於組件的體系結構，綁定和良好實踐

Question

跟隨我的問題Angularjs 1.5-CRUD頁面和組件

關於基於組件的體系結構，我還有其他一些設計問題。

1-根據准則，如果我有一個帶有父級綁定的子級組件，則應該在父級上處理數據操作。 因此，我是將數據保存在例如父級還是子級中？

例

 <my-child on-save="$ctrl.save"></my-child>

MyChild組件包含用於保存數據的表單。 在這種情況下，我應該將數據保存在父級還是子級中？ 假設我在子級中執行此操作，則使用父級保存功能來更新UI？

2-如果我有一個沒有綁定的子組件，這是正確的嗎？子組件中的數據保存和操作是否正確？

3-理想情況下，所有應用程序都應該是組件樹。 假設我有一個使用ng-view和router的表單。 通常，我必須考慮一個代表整個應用程序ui的核心或父組件，例如，我的表單是一個子組件？ 所以我必須傳播綁定，如點1和2？

希望我的問題清楚

Answer 1

好解釋一下，我首先必須考慮一些可能會改變您對應用程序設計的看法的組件。

組件

組件是對事物的通用定義，它既是一個整體的一部分，又是另一個整體的組成部分，但是它並未具體說明每個組件在該整體中的作用。 因此，在基於組件的體系結構中，通常會定義一些指令來以更好地定義每個角色的方式處理組件。

例如：一堆組件，一個組件又一個組件，但所有組件都組成；

<component>    
    <component></component>
    <component>        
        <component></component>
        <component></component>        
    </component>    
</component>

智能和啞巴組件

我已經讀到大多數基於組件的框架和庫都使用這種方法。 組件分為兩類，智能組件和啞組件。 Tero Parviainen的文章以及Dan Abramov對此進行了更好的描述。

例如：仍然是所有組件，但由其類別定義

<app>
    <nav></nav>
    <!-- projects-page is Dumb: I don't have to know nothing
    <!-- just organize and display things -->
    <projects-page>
        <!-- project-list is Smart: I must know how to retrieve projects -->
        <project-list>
            <!-- Dumb: just display -->
            <project-list-item></project-list-item>
            <!-- Dumb: just display -->     
            <project-list-item></project-list-item>
        </project-list>
    </projects-page>    
</app>

基本上， 智能組件已連接到應用程序邏輯，它們知道如何工作。 盡管他們可能有輸入和輸出，但是他們大多知道如何加載自己的數據，以及如何在發生更改時保持更改。 但是Dumb組件只是知道事物的外觀，並由其綁定完全定義：它們使用的所有數據都作為輸入提供給它們，而它們引入的每個更改都作為輸出（Tero Parviainen的Toward Smart And Dumb Components）輸出。

回答

因此，對於您的問題的答案是：這取決於您如何看待該子表單組件，如果它只是顯示字段的編輯器（即，啞子，在這種情況下，我認為是）。 或由檢索負責並命令與持久性統一的通信來保存它（即智能）。

無論如何，最重要的是確保您從智能組件（最好是從該數據的所有者）保存數據。 將智能組件視為管理者，而將愚蠢的組件（例如生產者）視為。 另外，請查看有關編寫基於組件的應用程序的文章：用Dima Grossman編寫的angular 1.5編寫基於組件的山羊約會應用程序 。

注意：將智能組件視為有狀態的。 從根本上講，這意味着智能組件在某些情況下很少重復使用。 如果您必須在對象project是另一個對象的一部分的另一個form-component上重用form-component （例如{ client: { name: '', projects: [{ id:1, ...} ...] ），並且您想使用相同的表單來編輯該對象中的項目，那么您將遇到問題。 您無法重用完全相同的組件邏輯，因此在這種情況下，啞巴組件對於重用可能會更有用，因為它在進行過程時更簡單，更客觀，並且無需做出任何決定，僅顯示事物，接收並返回數據。