# Ivy Update Instructions Revisited

## Problem
The current set of update (`RenderFlags.Update`) instructions do not fit our needs:
1. To correctly run the lifecycle hooks we need know when a set of bindings start and end for a particular directive. (See [FW-1051](https://angular-team.atlassian.net/browse/FW-1051) and [write up](https://docs.google.com/document/d/1BWw1w4u8dNUZOQPSyflTdAir2-VHMkIz3HSgPHUmDbM/))
2. #1 above is already a problem and has partial fix with [`elementStylingApply`](https://github.com/angular/angular/blob/a6ae759b46cae6211f3f5ab6a63fbb0acd7fdc41/packages/core/src/render3/instructions.ts#L1568-L1592). This is instruction is a symptom of the above problem.
3. We could shorten the generated code by removing `bind()` which is a very common instruction.
4. We could make the overall syntax shorter and more intuitive.

## Proposal

Given this template:

<div directive 
     id="{{expId}}"
     [name]="expName" 
     attr.title="Hello {{expTitle}}"
     [attr.aria]="{{expAria}}"
     [class.my-class]="classExp"
     ></div>

The current compiler implementation will generate:

function AppComp_Template(rf,ctx) {
  if (rf & 1) {
    element(0,'div');
    elementStyling(['my-class']);
  }
  if (rf & 2) {
    elementProperty(0, 'id', interpolate1('', expId, ''));
    elementProperty(0, 'name', bind(name));
    elementAttribute(0, 'title', interpolate1('Hello ', expTitle, ''));
    elementAttribute(0, 'aria', interpolate1('', expAria, ''));
    elementClassProp(0, 0, classExp);
    elementStylingApply(0);
  }
}

The crux of the problem is that `expId` will evaluate before `elementProperty`. To correctly do the life cycles on the components/directives we need to know where the binding boundaries are and we need to execute them before the expressions are evaluated. More details in [here](https://docs.google.com/document/d/1BWw1w4u8dNUZOQPSyflTdAir2-VHMkIz3HSgPHUmDbM/).

For the above reasons the new proposed ivy instruction set would be

function AppComp_Template(rf,ctx) {
  if (rf & 1) {
    element(0,'div');
    elementStyling(['my-class']);
  }
  if (rf & 2) {
    select(0);
    propertyInterpolate('id', expId));
    property('name', name);
    attribute1('title', 'Hello ', expTitle, '')
    attribute('aria', expAria);
    klass(0, classExp);
  }
}

### Savings

The above code has a slightly higher cost of +4 chars for the `select(0)`. However that added cost is offset by -2 for each binding and -3 for any duplicate binding of same type because of call chaining. Additionally, most of the new instructions do not require `bind()` or `interpolate()` method call which makes most of the -3 per simple (non-interpolated) bindings.

Finally notice that because of `select` we no longer need `elementStylingApply` which saves additional -4 chars. (explained in more detail later).

In the above example the savings are:
- `+4`| +4 for `select(0)`.
- `-3`| -2 for `id` and -4 for no `bind(...)` on `id`, but +3 for `,!0` flag to [optimize `interpolate`](#Optimizing-interpolate-exp-).
- `-7`| -3 for `name` and -4 for no `bind(...)` on `name`.
- `-6`| -2 for `title` and -4 for no `interpolate(...)` on `name`.
- `-13`| -3 for `aria` and -4 for no `interpolate(...)` and -6 for no `'',...,''` on `aria`.
- `-2`| -2 for `klass`
- `-4`| -4 for no need for `elementStylingApply(0)`

Total savings: -41 characters saved.

### Chaining

In the above example:

    select(0);
    property('id', expId))('name', name);

is just a shorthand for:

    select(0);
    property('id', expId));
    property('name', name);

this is because each ivy instruction returns itself for chaining purposes.

function property(...) { 
  ...
  return property;
}

### Renames

| Old Name | New Name |
|:---------------------|:-----------------------|
|`elementProperty` |`property`, `propertyInterpolate`, `propertyInterpolateX`
|`elementAttribute` |`attributeInterpolate`, `attributeInterpolateX`
|`elementStyleProp` |`style`
|`elementClassProp` |`klass`
|`elementStylingMap` |`styleMap`/`klassMap`
|`elementStylingApply` |[not needed](#Optimizing-interpolate-exp-)
|`textBinding` |`textInterpolate`, `textInterpolateX`

### Removing `bind()` and `interpolateX()`

Currently each `elementProperty()` instruction requires `bind()` like so `elementProperty(0, 'name', bind(exp))`. We can't inline the `bind` into the `elementProperty`, because the compiler could have generated `elementProperty(0, 'name', interpolate('', exp, ''))`. This would result in double dirty checking, and so we can't make `bind()` an implicit part of `elementProperty`.

In the new system:
- `elementProperty(..., bind(...))` will be same as `property(...)` and
- `elementProperty(..., interpolateX(...))` will be same as `propertyInterpolateX(...)`.
- `i18nExp(bind(...))` will be just `i18nExp(...)`.

For `attributeX` we can inline `attributeInterpolateX` into in similar way.

NOTE: the goal is to make `bind()` and `interpolateX()` to be internal implementation details and not visible to the compiler.

### Optimizing `interpolate('', exp, '')`

Bindings of this form are very common:

<div id="{{id}}">

This would result in

propertyInterpolate1('id', '', ctx.id, ''); // note the empty strings

We therefore have a special case for it in

propertyInterpolate('id', ctx.id);

To summarize the intructions we will be creating for interpolation:

- `propertyInterpolate1`-`propertyInterpolate8`: 1 to 8 interpolated values.
- `propertyInterpolateV`: More than 8 interpolated values.
- `propertyInterpolate`: For the common case `prop="{{foo}}"` to generate `propertyInterpolate('prop', ctx.foo)` instead of `propertyInterpolate1('prop', '', ctx.foo, '')`.

### Flushing and `select()`

The `select()` is needed to select the current element. Internally `select()` also needs to flush life-cycle hooks for the previous directives. Here is a pseudo code implementation:

let currentlySelectedElementIndex = 0;

function select(index) {
  // flush lifecycle upto this point.
  while(currentlySelectedElementIndex < index) {
    applyLifeCycleForDirectivesAt(currentlySelectedElementIndex);
    currentlySelectedElementIndex++;
  }
  currentlySelectedElementIndex = index;
}

NOTE:
- After the template is executed the framework needs to execute `select(consts +1)` so that it can flush the last directive (if any).
- `i18nApply()` is not a good candidate for auto applying as part of `select()` because it needs to be executed after each binding. (ie many times per one `select()` call).
- `pipeBind()` still has to remain because it is part of sub-expression and one can have many calls to `pipeBind()` for a single binding (ie having `{{exp | pipe1 | pipe2}}`)

### Why `elementStylingApply` is not needed

An explicit call to `elementStylingApply` was needed because style reconciliation needs to happen only once. Because `elementStyleProp`, `elementClassProp`, and `elementStylingMap` are all optional it is hard for the runtime to know when the last styling instruction was applied and reconciliation was needed. With the proposed change the reconciliation can be part of the `select` as shown in this pseudo code.

let reconcileStyles: (index:number)=>void|null = null; 

function elementStyleProp(...) {
  // This assignment is needed to make sure that 
  // `elementStylingApply` is tree-shakable.
  reconcileStyles = elementStylingApply;
  ...
} 

function select(index) {
  if (reconcileStyles) {
    reconcileStyles(currentlySelectedElementIndex);
    reconcileStyles = null;
  }
  ...
}

## Work Breakdown

|Status| Time Estimate |Description
|:-----|:--------------|:--
| | 1 week |Introduce `select()` call to flush life-cycle hooks [^dirFlush]
| | 2 weeks |Refactor binding instruction by joining them to bind/interpolate
| | 1 week |Refactor `elementStylingApply` to not be generated
| . | 2 weeks . |Chaining

[^dirFlush]: Marc Laval is already working on part of this.