binding: valueConverter doesn't observe array-valued object properties

@EisenbergEffect Can you link to those various considerations?

What if we handled this issue and the issue of computed properties with a similar solution? What if we start by expanding the syntax for computedFrom? Here’s a few things we might do:

Dependent on a simple property change: @computedFrom('firstName', 'lastName')

Dependent on property change and array value mutations: @computedFrom('lineItems[]')

Dependent on property change, array value mutations and array item property: @computedFrom('lineItems[].price')

Perhaps a nice TypeScript version via to-stringing function bodies of lambdas, using special known args. @computedFrom<Order>($index => this.lineItems[$index].price)

Then, once this basic capability is in place, we could build value converter updates on top of it by introducing a new, specially-recognized ObservableValue type. Value Converters could return this to provide not only the converted value, but also metadata about how that converter might need to update.

export class FilterValueConverter {
  toView(value, config) {
    return new ObservableValue(
      value.filter(x => x[config.property] === config.value), //the converted value
      '$value[].' + config.property //the observation expression(s) to indicate when to refresh
    );
  }
}

@jdanyow What do you think? Perhaps ObservableValue could even be something recognized in other places to provide control to end users? Am I crazy? These are our two biggest limitations so I was trying to see if we could kill two birds with one stone and maybe even open up some new possibilities we hadn’t thought of in other places.

Totally understand why you expect it to update- put simply, something changed… update the binding.

The thing is, the binding system has never eagerly observed collection mutation. There’s no logic (outside of the repeat) that checks this part of the expression evaluated to an array/map/set/etc… observe for mutation… Well that’s a little bit of a lie- there’s one spot that has a hack to support this feature request but it only handles arrays and it doesn’t really support a production use case. How often is someone really going to use string interpolation with a raw array? We should probably remove it because the logic to make it work is fairly complicated and ultimately makes this one scenario inconsistent with the way things are handled everywhere else in the binding system.

Adding logic to observe collection mutation everywhere an expression (or part of an expression in this case) evaluates to an array/map/set/etc would be a pretty radical change with serious perf implications. Would need to defer to @EisenbergEffect.

Hope all that makes sense. Apologies for the wall of text.