Status of knockout.es5

[knockout]

Status of knockout.es5

[brianmhunt]

@jfrank14 The plan is to use Proxy natively in TKO. A little documentation has been started, here:

https://github.com/knockout/tko/blob/master/packages/tko.computed/docs/proxy.md

Based on browser support Proxy is the correct solution, long term, but it's not as broadly supported as ES5 defineProperty.

The plan is for proxy to work with whatever validation scheme we come up with.

[caseyWebb]

Is it safe to assume that this will be exposed in the api for tko.builder? If that's the case I see no issue.

That said, the issue of backwards compatibility does leave a clear distinction between knockout-es5 and tko.proxy. I'm not sure if having support for both is worthwhile, but I do feel like proxies should come with a warning label; I've gotten bitten before because I assumed (as I hope I'm not alone), that I'd be able to polyfill for older browsers, and when this turned out not to be the case had to rewrite quite a bit of code.

[caseyWebb]

@brianmhunt Is tko.proxy intended to be opt-in? I really enjoy the syntax, but the inability to polyfill means it will be un-useable in any of our apps that need to target IE.

[brianmhunt]

@caseyWebb the plan is for proxy to be in tko but not knockout 4. On the spectrum of an app to dynamic Web page the Proxy is deep in Web app territory. Ko 4 will be backwards compatible to ie9.

[jfrank14]

Wait, what's the difference between tko and knockout 4. I thought they were the same thing!

I can't see a solution being viable that doesn't support IE at all. Even now it still has something like 9% market share and many app developers wouldn't be willing to tell users that their browser of choice just isn't supported. Can we not just continue to use defineProperty? What advantages does Proxy offer?

[brianmhunt]

@jfrank14 Among other benefits, the Proxy solution offers dynamics after initialization i.e. observable properties can be assigned after the object is created.

Properly speaking, tko is a monorepo that holds the source for the packages that can be combined to create Knockout, but tko itself can have more / other builds (and tko.js will be a reference implementation that will be mostly ko–compatible, save things like Proxy).

Knockout will continue to be as backwards compatible as is feasible (incl. IE 9+), so Proxy will be excluded.

[miellaby]

@brianmhunt can the Proxy solution do the same as this from knockout es5 doc?

If you want to restrict which properties are upgraded to observability, pass an array of property names:
ko.track(someModelObject, ['firstName', 'lastName', 'email']);

My concern with transparent observable wrapping is that it may create a lot of useless observables. It's definitely not reasonable to wrap every attribute of every item of a huge collection. In my team, I always recommend to manage collection elements as immutable objects with the minimum amount of observables for a given purpose.

[brianmhunt]

@caseyWebb Agree; we want to be clear on the distinction between tko and ko — highlighting backwards compatibility.

@miellaby tko.proxy in master can't do that, but I've only to mull the API a bit more.

I've nothing against knockout-es5 or equivalent being in ko proper, but it's not a pain point for me and the drawbacks (that Proxy overcomes) give me pause about it.