BETTER SUPPORT FOR FUNCTIONAL PROGRAMMING IN ANGULAR 2

In this blog post I will talk about the changes coming in Angular 2 that will improve its support for functional programming.

Angular 2 is still in active development, so all the examples are WIP. Please focus on the capabilities and ideas, and not the API. The API may change.

WHY FUNCTIONAL PROGRAMMING

Imagine an application being a nested structure of components. And it is written in the way that

  • A component depends only on its bindings and its direct children.
  • A component directly affects only its direct children.

Nested Components

For example, the highlighted Todo component should not be able to affect any other component except for the input elements.

If we write our application in this way, we get the property:

We can effectively reason about every single component without knowing where it is used. In other words, we can reason about a component just by looking at its class/function and its template.

We want to limit the number of things we need to look at to make a change. And we want to make changes predictable and controlled. This is the goal, and functional programming is just the means of achieving it.

DATA-ORIENTED PROGRAMMING

Using a mutable domain model goes against our goal. Say we have a mutable domain model that backs up my component. And the component updates the model. Some other component, somewhere else, that happened to point it, will be updated.

Instead we should model our domain using dumb data structures, such as record-like objects and arrays, and transform them using map, filter, and reduce.

Since Angular does not use KVO, and uses dirty-checking instead, it does not require us to wrap our data into model classes. So we could always use arrays and simple objects as our model.


class TodosComponent {
  constructor(http:Http) {
    this.todos = [];

    http.get("/todos").
      then((resp) => {
        this.todos = resp.map((todo) =>
          replaceProperty(todo, "date", humanizeDate))
      });
  }

  checkAll() {
    this.todos = this.todos.map((todo) =>
      replaceProperty(todo, 'checked', true));
  }

  numberOfChecked() {
    return this.todos.filter((todo) => todo.checked).length;
  }
}

Here, for example, todos is an array of simple objects. Note, we do not mutate any of the objects. And we can do it because the framework does not force us to build a mutable domain model.

We can already write this kind of code in Angular today. What we want is to make it smoother, and take advantage of it performance wise.

USING PERSISTENT DATA STRUCTURES

For example, we want to improve the support of persistent data structures.

First, we want to support even most exotic collections. And, of course, we do not want to hardcode this support into the framework. Instead, we are making the new change detection system pluggable. So we will be able to pass any collection to ng-repeat or other directives, and it will work. The directives will not have to have special logic to handle them.

<todo template=”ng-repeat: #t in: todos” [todo]=”t”></todo> // what is todos? array? immutable list? does not matter.

Second, we can also take advantage of the fact that these collections are immutable. For example, we can replace an expensive structural check to see if anything changed with a simple reference check, which is much faster. And it will be completely transparent to the developer.

CONTROLLING CHANGE DETECTION

Functional programming limits the number of ways things change, and it makes the changes more explicit. So because our application written in a functional way, we will have stronger guarantees, even though the JavaScript language itself does not provide those guarantees.

For example, we may know that a component will not change until we receive some event. Now, we will be able to use this knowledge and disable the dirty-checking of that component and its children altogether.

A few examples where this feature can come handy: * If a component depends on only observable objects, we can disable the dirty-checking of the component until one of the observables fires an event. * If we use the FLUX pattern, we can disable the dirty-checking of the component until the store fires an event.

class TodosComponent {
  constructor(bingings:BindingPropagationConfig, store:TodoStore) {
    this.todos = ImmutableList.empty();
    store.onChange(() => {
      this.todos = store.todos();
      bingings.shouldBePropagated();
    });
  }
}

FORMS & NG-MODEL

Our applications are not just projections of immutable data onto the DOM. We need to handle the user input. And the primary way of doing it today is NgModel.

NgModel is a convenient way of dealing with the input, but it has a few drawbacks:

  • It does not work with immutable objects.
  • It does not allow us to work with the form as a whole.

For instance, if in the example below todo is immutable, which we would prefer, NgModel just will not work.

<form>
 <input [ng-model]="todo.description">
 <input [ng-model]="todo.checked">
 <button (click)="updateTodo(todo)">Update</button>
</form>

So NgModel forces us to copy the attributes over and reassemble them back after we are done editing them.

class TodoComponent {
  todo:Todo;
  description:string;
  checked:boolean;

  actions:Actions;
  constructor(actions:Actions){
    this.actions = actions;
  }

  set todo(t) {
    this.todo = t;
    this.description = t.description;
    this.checked = t.checked;
  }

  updateTodo() {
    this.actions.updateTodo(this.todo.id,
      {description: this.description, checked: this.checked});
  }
}

This is not a bad solution, but we can do better than that.

A better way of dealing with forms is treating them as streams of values. We can listen to them, map them to another stream, and apply FRP techniques.

Template:

<form [control-group]="filtersForm">
  <input control-name="description">
  <input control-name="checked">
</form>

Component:

class FiltersComponent {
  constructor(fb:FormBuilder, actions:Actions) {
    this.filtersForm = fb({
      description: string, checked: boolean
    });

    this.filtersForm.values.debounce(500).forEach((formValue) => {
      actions.filterTodos(formValue);
    });
  }
}

We can also take the current value of the whole form, like shown below.

Template:

<form #todoForm [new-control-group]="todo">
  <input control-name="description">
  <input control-name="checked">
  <button (click)="updateTodo(todoForm.value)">Update</button>
</form>

Component:

class TodoComponent {
  todo:Todo;

  actions:Actions;
  constructor(actions:Actions) {
    this.actions = actions;
  }

  updateTodo(formValue) {
    this.actions.updateTodo(this.todo.id, formValue);
  }
}

SUMMARY

  • We want to be able to reason about every component in isolation. And we want changes to be predictable and controlled. Functional programming is a common way of achieving it.
  • Data-oriented programming is a big part of it. Although Angular has always supported it, there are ways to make it even better. For example, by improving support of persistent data structures.
  • When using functional programming we have stronger guarantees about how things change. We will be able to use this knowledge to control change detection.
  • The current way of dealing with dealing with the user input, although convenient, promotes mutability. A more elegant way is to treat forms as values, and streams of values.
    • Gibberish. All of this looks like gibberish.

    • 10  
    • Reply
    •  
       
      •  
         
        Avatar

        Agree. Two years working everyday with Angular 1.x and this feels like a completely different language/framework. Why not slowly introduce these V2 features every release over a couple of years instead of invalidating everyone's experience overnight and making all existing components redundant? This might go down in history as an example of how to destroy a grassroots community by pandering to a computer science elite. Who is to say they won't throw all this it out and start again with Angular 3.0?

      •  
      • Reply
      •  
         
      •  
         
        Avatar

        I have a feeling his posts are not for a completely general audience and that there are quite a few specific prerequisites to being able to fully understand them; namely, being familiar with ES6 syntax, being moderately familiar with the angular 2 design docs, and perhaps being somewhat involved or actively following the angular 2 development.

        I wouldn't take his posts as some sort of Angular 2 sneak peek or tutorial, but rather as mini white papers that are exploring the challenges and topics that the Angular 2 team themselves are running up against.

      •  
      • Reply
      •  
         
    •  
       
      Avatar

      Victor, I've been using angular for over a year and I have experience with FP and immutable data using Flux in React (seehttps://github.com/gilbox/vizo... and https://medium.com/@gilbox/how.... Yet, as ngDeveloper mentioned, your code examples are extremely difficult to understand. I think a big part of the confusion is that I can't seem to find any information about the angular 2.0 template syntax you're using. I know you said that the API is going to change, but there are too many new constructs here to allow me to see the forest from the trees. What is control-group and new-control-group? What is #todoForm? What is FormBuilder? Can you provide any additional information and/or links?

    •  
    • Reply
    •  
       
    •  
       
      Avatar

      Ahh... yeah... this 'feel's a lot like Java 8 ... loving it so far...

    •  
    • Reply
    •  
       
    •  
       
      Avatar

      I don't understand this

      set todo(t) {
      this.todo = t;
      this.description = t.description;
      this.checked = t.checked;
      }

      Where is set todo being called?

    •  
    • Reply
    •  
       
      •  
         
        Avatar

        The change detection will call "set todo" when updating the todo property of this component.

      •  
      • Reply
      •  
         
        •  
           
          Avatar

          There is no ChangeDetector in TodoComponent, so how the change detector knows it has to call "set todo"? Ist this a sort of convention that a component needs a "set" method(s)?

        •  
        • Reply
        •  
           
          •  
             
            Avatar

            Imagine you have something like this <my-component [todo]="t"> in your template.

            What it means is that when the binding `t` changes, Angular will set the new t on my-component (myComponent.todo = newT). And if you override the setter, it will be invoked.

            So todo is not special, and there is no convention. You have to explicitly declare what properties you want to be updated (i.e., to bind them) in your template.

            We are working hard on getting some basic docs out there.

          •  
          • Reply
          •  
             
            •  
               
              Avatar

              To me (myComponent.todo = newT) means I need either "set todo()" in myComponent or there is a "todo" attribute in myComponent (which is fine, as I have <my-component [todo]="t"> in my template). Can I have a method like "updateTodo(newT) { this.todo = newT}" in myComponent and use it in template e.g. <my-component [updatetodo]="t"> ?

            •  
            • Reply
            •  
               
              •  
                 
                Avatar

                The way you should think about it:
                - my-component has the todo property
                - The binding does not invoke the function, it just updates the property. The fact that the property can have a setter does not change this.

                When you write you code:
                - You should avoid having setters.
                - If you do have to have them, they should contain only simple transformations and be idempotent.

                If you want to write <my-component [updatetodo]="t"> you have to have a setter `set updatetoto`.

              •  
              • Reply
              •  
                 
    •  
       
      Avatar

      So, can we now dirty-check only bindings in one component instead of all the bindings in app?

    •  
    • Reply
    •  
       
    •  
       
      Avatar

      Nice overview of how it will look. Very much what like what React/Flux seems to be, but with angular templating. I hope this approach will help push the benefits of functional programming within my dev team, now that we're already on the angular bandwagon.

    •  
    • Reply
    •  
       
      •  
         
        Avatar

        Thank you.

        >> Very much what like what React/Flux seems to be.

        Similar to React you do not have to go with the functional approach if you do not want to. The idea is not to make it as painless as possible. So the teams that prefer this style of programming will be able to use it.

        >> I hope this approach will help push the benefits of functional programming within my dev team

        One of the things I am thinking about these days is what kind of tooling we can provide to make it easier for the teams who are not very experienced with FP. I have a few vague ideas, but nothing concrete.

      •  
      • Reply
      •  
         
      •  
         
        Avatar

        Hopefully it has more documentation than Flux lol

原文地址:https://www.cnblogs.com/eebb/p/4402386.html