SOLID properties, modularity, and knockout segregation

[bluebaroncanada]

I just started learning Knockout. I come from a background of highly maintainable and extensible projects. I preach the bible of Bob Martin and his SOLID principles.

I was a little bit confused about how KO purports to be MVVM, yet, in the documentation--and truly, it seems, in implementation--that it appears as though you're attaching view-model assets to the data models; namely observables.

Please excuse me because I definitely could be missing something and I'm definitely, humbly, and deferentially laying this at your feet.

I believe, though, we should be able to have POJO/POTO (Plain Old JavaScript/TypeScript Object) models. We may want to use those models for other things like building a database or other extensible reasons. I considered mapping or separate models for the view and data, but both present the following problem: Those two solutions require updating models in more than one place. I could, with TypeScript, use an interface, but I would still have to update in more than one spot, so I don't relish the prospect any more than the other two options, though, it is type safe.

Another avid KO developer--whom I won't mention, but I will link him this thread and allow him the opportunity to comment if he likes--and I put our heads together and came to the realization that you should be able to bind to the outer object of an instance of a class. He actually started, in earnest, to write something of the sort. The problem, though, he came across is illustrated in this thread and he points to this comment: microsoft/TypeScript#12114 (comment) Apparently it's not yet supported by TypeScript to descend the dependency chain, making deep mapping impossible.

Also, we would need some mechanism to only bind what we need. I suggested something like:

ko.observe(foo, ['name', 'address' ...

but that's hard to do deep comparisons on and is still not DRY code. Possibly class annotations would be better.

One of the main things that I know from preaching SOLID is that frameworks should be abstracted to the max. I may want to replace KO someday with a newer version or another framework. I should be able to have the smallest pieces of my code reliant on KO.

Thanks for listening.

[bluebaroncanada]

Maybe it's best to just hide the observable stuff from the user and automatically do it when something in the view requests a binding.

[brianmhunt]

Thanks @bluebaroncanada for the apt description.

IMHO, the correct solution will be to eventually wield the Javascript Proxy to handle dependency chaining.

Proxy is not exceptionally well supported yet, but it's coming along.

Until the Proxy is widely supported, the only alternative is caking layers onto the data models. That yields one problem or another, usually with trade-offs that rival the problem being solved.

In the interim though, there is the knockout-es5 project – but again, it has trade-offs.

I'll close this issue as there's nothing strictly actionable here, but I do take your point. 😄 If there is something we can do now, we can re-open. In any case, please feel free to continue discussion.

[bluebaroncanada]

@brianmhunt You're probably right. I'll have to check into it. Thanks for keeping this in mind, though. Someone else mentioned to me another project.
What do you think of this?
https://github.com/ConrabOpto/komx

[brianmhunt]

Thanks @bluebaroncanada :) .

komx looks neat, and actively maintained. I've never used it, but it looks like it's solving a problem at the data layer along the lines of what you were thinking.