Consider adding `$bind` and `$unbind` to all AST nodes (and remove them from observers)

[fkleuver]

Consider adding `$bind` and `$unbind` to all AST nodes (and remove them from observers)

[bigopon]

Doing this allow us to enable the following:

<div>${(firstName | capitalize) + " " + lastName}</div>

Basically when everything flows though, it's easy to have nested value converter, Binding behavior should still happen per binding

[fkleuver]

Yep it does. We can also have nested Binding behavior. It's the same binding that flows through the bind calls, and it's the binding you modify

[bigopon]

@fkleuver binding behavior is supposed to modify binding, so it makes sense to have per binding and perhaps not possible to make it per expression, that's what I thought. Maybe you saw some direction for improvement?

[fkleuver]

Additional possibilities for the binding behavior is one of the main reasons I raised this issue in the first place.

A rough idea I had is to have the AST expose a lightweight configuration API that allows you to set/unset flags on specific expressions.
Those flags can either be stored in an expression map per bound scope or per binding (I'd need to experiment with what works and what the perf implications are)

This would be useful for applying binding behaviors to only a certain part of an expression, e.g. foo.bind="(bar & oneTime) + baz" (baz is connected but bar is not) but it would also open up the possibility of modifying the behavior of an expression by cloning it for a particular binding and then monkey patching the connect, assign or evaluate method. For instance to enable two-way binding on expressions that normally don't allow it such as unary/binary/ternary. If the consumer knows how the target value needs to be reverse-evaluated, then it can be two-way bound.

I don't know yet if all of this would make sense and we'd need to take a close look at whether it's all worth the trouble. Too early to say anything without any experimentation

[EisenbergEffect]

It would be nice if there was a better API for binding behaviors other than monkey patching methods. The current way of writing them feels hacky and prone to error. It's not a hard requirement to improve this, but it would be very nice I think.

[fkleuver]

Agreed. I'm thinking something among the lines of this:

IBinding {
  applyBehavior(behavior: IBindingBehavior): IBinding;
}

IBindingBehavior {
  updateTarget?(binding: IBinding, value: any): void;
  updateSource?(binding: IBinding, value: any): void;
  handleChange?(binding: IBinding, newValue: any, oldValue: any): void;
  $bind?(binding: IBinding, flags: BindingFlags, scope: IScope): void;
  // etc
}

export class Binding {
  public updateTarget(value: any): void {
    // more optimized/intelligent of course, a bit similar to subscriberCollection
    if (this._behavior1) {
      this._behavior1.updateTarget(this._behavior0, value);
    } else if (this._behavior0) {
      this._behavior0.updateTarget(this, value);
    }
  }
}

export class SomeFooBindingBehavior implements IBindingBehavior {
  public updateTarget(binding: IBinding, value: any): void {
    // some magic
    if (value === undefined) value = null;
    binding.updateTarget(value);
  }
}

And of course the normal $bind method if you need to just set the mode or do funny stuff like rebasing an expression (thinking of a better API for that too)

[EisenbergEffect]

It would be good to get some feedback from @zewa666 on this since he built some custom behaviors for the i18n plugin that we want to port to vnext.

[zewa666]

This sounds pretty nice. BindingBehaviors currently feel a bit hacky so everything we do here for cleaning up the API is a big win. The config part that @fkleuver mentioned could be useful for certain i18n use-cases

[fkleuver]

Will not do this, the performance impact is too much actually.