Hi Andrew, Can you give me a scenario where a writable computed observable would be required? As the KO site states, these are very uncommon, mainly because the computed nature of the observable makes them unnecessary. If you need an update, set one or more of the dependent observables, and the computer observable also reflects the change.
I would like built-in support for nested properties in the model, particularly when binding controls to odata and using the expand option to fetch related data via a foreign key. If the grid were aware of this, then setting column templates on foreign keyed data could be much easier as would using them to filter rows. Achieving this today requires a lot of extra code and you can see an example at at http://www.telerik.com/account/support-tickets/view-ticket.aspx?threadid=880807 There are some other suggestions here that are similar but they each suggest something that doesn't quite make it universally useful. However, based on those suggestion it appears that this support would be useful for many things.
Current way of implementing functions in viewmodels suck because you have to use this.get and this.set to access the viewmodel properties. The syntax would be much prettier if you can use advantage of TypeScript strong typing.
For performance reasons, it would be nice to be able to stop the change notification for the change of a single property value on a single item in an ObservableArray (or DataSource) from causing the whole ObservableArray from raising a change notification for its bindings. This causes all the bindings for all the items to be re-evaluated.
It would be nice to have some additional "flow control" for the MVVM framework, including ... "if" - <div data-bind="if: [property]"> // renders if the given value is true </div> and "not" <div data-bind="not: enabled"> // renders if the given value is false </div> and "each" <div data-bind="each: array"> // renders this section for each item in the array given </div> I know some of this can be achieved with templates, but this would make it very convenient and mean we did not have to use templates everywhere, and could lead to much more natural coding.
MVVM is still lacking some of the capability that is provided by the standard widgets. For example a tooltip cannot bind it's content property to a function in a viewmodel.