AngularJs 1.5-基于组件的体系结构，绑定和良好实践 [英] AngularJs 1.5 - Component Based Architecture, Bindings and Good Practices

问题描述

跟随我的问题 Angularjs 1.5-CRUD页面和组件

关于基于组件的体系结构，我还有其他一些设计问题.

I've some additional design questions on component based architecture.

1-根据准则，如果我有一个带有父级绑定的子组件，则应该处理父级上的数据操作.因此，我是将数据保存在例如父级还是子级中?

1- By Guidelines, if I have a child component with bindings from a parent, I should handle data manipulation on the parent. SO, were do I save data, for instance, in the parent or in the child ?

示例

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

MyChild组件包含用于保存数据的表单.在这种情况下，我应该将数据保存在父级还是子级中?假设我在子级中执行此操作，我使用父级保存功能来更新UI?

MyChild component contain a form for saving data. In this scenario, where I should save data, in parent or child ? Assuming I do it in child, I use the parent save function for updating the UI ?

2-如果我有一个没有绑定的子组件，这是正确的吗?子组件中的数据保存和操作是否正确?

2- If I have a child component without bindings is it correct do do data saving and manipulastion in the child?

3-理想情况下，所有应用程序都应该是组件树.假设我有一个使用ng-view和router的表单.通常，我必须考虑一个代表整个应用程序ui的核心或父组件，例如，我的表单是一个子组件?所以我必须像第1点和第2点那样传播绑定?

3- Ideally all the application should be a component tree. Let's say I have a form, called using ng-view and router. In general I have to think to a core or parent component, representing the entire app ui, for which, by instance, my form is a child ? SO I have to propagate bindings like in points 1 and 2 ?

希望我的问题很清楚

推荐答案

首先，我必须考虑一些组件，这些组件可能会改变您对应用程序设计的看法.

Well to explain this I first have to make some considerations about components that might change your view about your application design.

Component是对事物的通用定义，该事物既是一个整体的一部分，又是另一个整体组成的，但是它并没有具体说明每个组件在该整体中的作用.因此，在基于组件的体系结构中，通常会定义一些指令来处理组件，从而可以更好地定义每个角色.

Component is a generic definition for something that is both a part of a whole and composed by another whole, but it doesn't especify nothing about the role of each component in that whole. Therefore, in a component based architecture normally is defined directives to deal with components in a way that can define better each roles.

例如:一堆组件，一个组件又一个组件，但所有组件都组成

For example: bunch of components, one composite by another but all components;

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

智能和哑巴组件

我已经读到大多数基于组件的框架和库都使用这种方法.组件分为两类，智能组件和哑组件.此 Tero Parviainen的文章，也来自例如:仍然都是组件，但由其类别定义

For example: still, are all component, but defined by its category

<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>

基本上， Smart 组件已连接到应用程序逻辑，它们知道思考的原理.尽管他们可能有输入和输出，但他们大多知道如何加载自己的数据，以及如何在发生更改时保持更改.但是 Dumb 组件只知道事物的外观，并由其绑定完全定义:它们使用的所有数据都作为输入提供给它们，它们引入的每个更改都作为输出出现，迈向明智之举哑巴零件，Tero Parviainen的.

Basically, Smart components are connected to the application logic, they know how thinks works. Though they may have inputs and outputs, they mostly know how to load their own data, and how to persist changes when they occur. But Dumb components just know how things should look like and are fully defined by their bindings: All data they use is given to them as inputs, and every change they introduce comes out as an output, Toward Smart And Dumb Components, Tero Parviainen's.

因此，您的问题的答案是:这取决于您如何看待该子表单组件，如果它只是显示字段的编辑器(即，在这种情况下我认为是哑巴).或由检索负责并命令具有持久性统一的通信来保存它(即智能).

So the answer for your question is: it depends on how you see that child form component, if it is just an editor to display the fields (i.e., dumb, which I think in this case it is). Or is responsible by the retrieve and commands the comunication with the persistence unity to save it (i.e., smart).

无论如何，最重要的是确保您从智能组件(最好是从该数据的所有者)保存数据.可以将智能组件视为管理者，而将愚蠢的组件(如生产者)考虑在内.另外，请查看有关编写基于组件的应用程序的文章:编写基于组件的山羊Dima Grossman编写的角度为1.5的约会应用程序.

Anyhow, the most important thing is to make sure you are saving your data from a smart component, preferably, from the owner of that data. Think about smart components as managers and dumb components like producers. Also, check this articles about writing component based applications: Writing component based goats dating app with angular 1.5 written by Dima Grossman.

注意:将智能组件视为有状态的.从根本上讲，这意味着智能组件在某些情况下不太可重用.如果必须在对象 project 是另一个对象的一部分的另一个组件上重用 form-component (例如， {client:{name:''，项目:[{{id:1，...} ...] )，而您想使用相同的表单在该对象中编辑项目，您将遇到问题.您无法重用完全相同的组件逻辑，因此在这种情况下，哑巴组件对于重用可能更有用，因为它在进行过程时更加简单和客观，并且无需做出任何决定，仅显示事物，接收并返回数据.

NOTE: Think about smart components as stateful. It basically means that smart components are less reusable in some cases. If you have to reuse the form-component on another component where the object project is a part of another object (e.g., { client: { name: '', projects: [{ id:1, ...} ...]) and you want to use the same form to edit the project within this object you'll face an issue. You can't reuse the exact same component logic, therefore in this situation a dumb component can be more useful for reusing, because it's more simple and objective with a proceeding and it doesn't take any decision, just show things, receive and return data.

这篇关于AngularJs 1.5-基于组件的体系结构，绑定和良好实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！