Split out Knockout Components from core into a separate module

[kmalakoff]

Regarding #1517, I've been giving it some more thought and believe you should consider removing the components framework from Knockout core and releasing it separately.

The scope of Knockout core should be more around data-binding rather than application architecture.

[SteveSanderson]

There could always be arguments for splitting things out (components, observables, extenders, data binding, templating). In an ideal situation, it would even be possible to produce your own builds containing whatever subset of functionality you want. As of today we've made a set of pragmatic decisions to get to where we are with a tight but reasonably functional core, all for good reasons justified at the time.

I'll close because I'm not sure what else could be done with such a request. Sorry!

[kmalakoff]

@SteveSanderson I think you should look at this from a product standpoint more than a plugin standpoint. If you answer: "What is the core value of Knockout?" and see if you can deliver that value with or with certain functionality, it will help to define the core product

As a customer of Knockout, I chose it for it's two-way bindings so to me, that's the core. Everything else I I use I have selected for best fit:

I use Knockback and BackboneORM for bringing data into Knockout so I'm glad you didn't make https://github.com/SteveSanderson/knockout.mapping part of the API. I use Backbone.Router for routes, but have used other libraries like HistoryJS from your Mobile-like flow tutorial in the past. I use Webpack for providing a CommonJS/AMD compatible require and application packaging solution. I use https://github.com/WebReflection/document-register-element for WebComponents.

If you were to provide any of the these pieces, I'd suggest the same thing: non-core.

I would treat web-components the same way, it is not part of the core of Knockout's two-way data binding promise, but steps into application architecture so it should external be like knockout.mapping. By this logic, observables, extenders, data binding, templating are part of the Knockout two-way data binding promise so they belong in core.

I definitely do not need to produce my own builds as long as you keep core small around a valuable promise ;-)

[maskmaster]

I am also questioning the bundling of the components/web components in KO. I am using compositions and widgets from Durandal currently. Since the components from KO is not used I get unused code bundled in my solution.

The one thing I have underscored to colleagues when discussing whether to use KO or not is that it is a package that has one specific responsibility which it handles well - the VM <-> View bindings. That makes it just as an easy choice as using gzip for encoding. I know I won't get lots of other dependencies.

Let me be clear. I am not questioning the KO components implementation. From what I have seen so far it could be a future choice of mine with the nested components and all.

If there is no technical reason for including the component implementation into KO I think is would be wise to treat it just like @kmalakoff suggest. Move it to a separate package like knockout.mapping and punches and the like, so that I can include it when I so desire.

[brigand]

Keeping it in the core encourages people to use KO components in third party libraries. Otherwise you need to weigh the costs of depending on people including the components library. I think it's a very sensible and important feature.

It doesn't make assumptions about the rest of your stack, it just fills in a missing piece of KO core functionality and defines a common language for third party developers.

[maskmaster]

First: What is the responsibility for knockout? In my book it has always been doing view-bindings really well. This is why I have recommended people to use KO. It will not (implicitly) force other things on you (Angular, I am looking at you.)

Like the original submitter pointed out, where will knockout draw the line? Should all the capabilities of Durandal be included. Or just the composition stuff? Isn't knockout punches more knockout core than components?

The Unix motto, do one thing and do it well, is a good principle.

Second: It could also be that third party developers are put off by this "encouragement". If you start to embrace and extend their parts into knockout, they might feel side-stepped, and ditch knockout for their own solutions. I am not saying this is the main reson for the developments in the coming version of Durandal, but I do not like that Durandal is becoming monolithic, as well as knockout. There was a clear separation of concern before. Just including the components in the knockout package "forces" me to use it, because I can promise that later on more core functionality comes along that assumes that you use knockout's components, no others.

Finally: There are still many ways knockout can improve in the core. Performance, code cleanups, supporting new browser features while still supporting IE8 etc. See #1600, #1584, #1650 - With @brigand's suggested solution in my mind. And a lot of other core issues.

I would love to see a really tight and clean implementation for components, but as an optional add-on. Make it easy for developers to pick and choose the libraries you want, and make it possible to retire parts that are not on par anymore.

[stalniy]

You can modify "build/fragments/source-references.js" and build your custom Ko version without components. Also you can omit odd bindings or template engine

[kmalakoff]

@stalniy I really do believe I should have to dive into the internals of the Knockout build system to use the Knockout library.

If you provide a way to bower install and npm install your proposal, I'll take it.

[brianmhunt]

@kmalakoff I'm with you — it'd be delusional to expect users to recompile Knockout to remove components. As awesome as components are, I am also on "team-component-plugin". That said it's not practical to rip it out now. What can be done is keeping this issue in mind and making sure that the knockout components code remain at least nominally loosely coupled in future patches.

Speculating, it'll probably be 4.0 or later before that happens, and if components are someday transformed into a plugin it'll probably (and not to be presumptuous, but just thinking out loud) coincide with a change in the nature of plugins e.g. #1589 .

Over time I have come to notice based on my own practices that there are some “first-class” plugins that make sense to bundle with the core package (e.g. components, knockout-punches, knockout-projections), and a slew of ”second-class” packages that are hosted elsewhere. The delineation between first and second class should only ever be hosting-for-convenience, with no special design privileges in the core that prejudice the second-class. (In this sense I feel "first" and "second" class may be derogatory language already ... maybe "core" plugins and just "plugins", but for the purpose of this paragraph, it's illustrative).

That said, I do not know what the other maintainers are thinking the direction of knockout components ought to be, but I'm sure it'll come up in discussion, and I'll raise this if no-one else does. :)

[rniemeyer]

Backwards compatibility has always been a key concern and goal for KO, so it is not practical to pull components into a plugin in the short-term.

Including this functionality in core vs. as a plugin was discussed during the original design. In the end, we wanted the components functionality to be light and extensible (plugins can be built on top of it), but available to new/all KO developers from day one as a pattern for development vs. new folks commonly ending up with large, hard-to-maintain view models as their application grows. It has always been possible to write modular, reusable code with KO, but the barrier was often high for those that were new to KO.

[kmalakoff]

In Knockback, I provide two versions: 1) core 2) full.

Users can then choose...a full version with the major plugins bundled or start from core and add the plugins they want.

Easy peasy.