javascriptangularjscomponent-based

AngularJs 1.5 - Component Based Architecture, Bindings and Good Practices

following my question Angularjs 1.5 - CRUD pages and Components

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

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 ?

Example

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

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- If I have a child component without bindings is it correct do do data saving and manipulastion in the child?

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 ?

Hope my question is clear

Solution

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

    Components

    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>

    Smart and Dumb components

    I've read that most of component-based frameworks and libraries use this approach. Components are separated in two categories, Smart and Dumb components. This is better described by this Tero Parviainen's article and also by Dan Abramov.

    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>

    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.

    Answer

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

    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.

    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.