Roadmap to KO 1.3

[fla...@gmail.com]

Hey folks

I'd like to start a conversation about some ideas for version 1.3.
There are a few big features I've been wanting to include for a while,
and the time seems right to put them in here. If you have other ideas
about what new functionality would benefit the majority of KO users
(without changing the entire scope of the project - e.g., there is not
going to be any server-side code!) please say so.

What I have in mind is:

Control flow bindings
===============
By giving bindings the ability to control binding of descendant nodes,
it becomes possible to add bindings like "if", "with", and "foreach"
that modify the DOM in a lightweight, convenient way without making
you use so many templates all the time.

* "if" would include/exclude descendant nodes, and means you don't
have to write "text: someChild() ? someChild().childProperty : null"
in case someChild() would be null, as you could wrap a section of the
DOM with "if: someChild".
* "with" would do the same as "if", plus it would change the binding
context to the supplied value. This lets you bind a section of
elements against a specific object, meaning that you can reference
their properties directly (e.g., "text: childProperty") instead of
forcing you to use fully-qualified references (e.g., "text:
someChild().childProperty").
* "foreach" would do the same as "with", except it operates on an
array and adds/removes descendants as items are added/removed in the
array.

Try these running prototypes right away :) :
* if: http://jsfiddle.net/cJzzc/
* with: http://jsfiddle.net/jm9W8/
* foreach: http://jsfiddle.net/p7sUB/

These bindings don't replace templates entirely; they just give you a
lightweight, convenient alternative in many simple cases.

Inline templates
===========
The much-requested feature! Lets you replace this:

<div data-bind="template: { name: 'myTemplate', data: someObject }"></
div>
<script id="myTemplate" type="text/html">
Template markup goes here
</script>

... with this:

<div data-bind="template: someObject" style="display:none">
Template markup goes here
</div>

Extenders
=======
Often, people want to modify the behavior of an observable. For
example, you might want to ensure it only holds a numeric value. One
way you can already do it is by creating a function that returns a
writable dependent observable with your intended behavior, but this
isn't obvious and it's hard to combine multiple behaviors.

The idea of extenders is a bit like binding handlers - you can
register a set of extension functions that can be called when
initialising an observable or dependentObservable. For example, you'll
be able to initialise an observable like this:

var viewModel = {
myValue : ko.observable(0).extend({ numeric: true })
};

... as long as there is also a handler for "numeric", e.g.:
ko.extenders.numeric = function(target) {
return ko.dependentObservable({
read: target,
write: function(value) {
if (!isNaN(value)) { target(value) }
}
});
}

So, you can define your own library of extenders (or ask for help from
the community in creating one), and then easily merge the behaviors
into your view model. The other nice thing about this is that you can
compose behaviors together, for example you could define a "throttle"
extender that makes an observable that cannot notify faster than a
certain rate (e.g., once per second), and then combine the two
behaviors:

myValue : ko.observable(0).extend({ numeric: true, throttle:
2000 }) // Is numeric and updates no faster than once every 2 seconds
(2000 milliseconds)

History integration (may be a plugin)
==========================
I think there's huge potential for linking observables with URL
components, somewhat like Alisson has been showing here:
http://groups.google.com/group/knockoutjs/browse_thread/thread/75dbfeee65988569

I'd love to see a standard KO plugin for doing that linking. I don't
think it needs to tackle all the "single-page interface" details like
loading external templates, but if it just handled the core
observable<-->URL link, you can layer any form of navigation or
template management on top of that.

============

So, let me know what you think. The roadmap presently is:
* Implement and release 1.2.1, which should fix most of the
outstanding issues at https://github.com/SteveSanderson/knockout/issues
* In parallel develop 1.3.0 (on this branch:
https://github.com/SteveSanderson/knockout/tree/1.3) and release later
when done.

[Ω Alisson]

All new features are really cool, Steve. The "foreach" binding has potential to replace most of the common template code, so is it too slow compared to the traditional approach?

[Arxisos]

Hi,

these are really great ideas!

Especially, I like "Control flow bindings", because this would be a performance boost, wouldn't it?

Lets say we create a normal template if some if-statements.

So the whole template needs to be rerendered after an observable in an if-statement changes, but with this feature, only the part in the if-statement will be rerendered. 

So thumps up for this idea!

But are the native template features like if, foreach etc still useful with this feature? I think, because of the performance boost with control flow bindings, nobody will use native statements.

So, what do you think, is a template system with if, foreach, ... support still necessary? 

The only argument which I find against the control flow bindings when you compare them with native template system features is, that you need to create a node in the DOM when you add a binding.

For example:

<script type="text/template">

  {{if observable > 0}}   

    <div id="...">SomeContent</div>

    <span class="...">SomeText</span>

  {{/if}}

</script>

But with control flow bindings:

<script type="text/template">

   <div id="wrapperDiv" data-bind="if: observable" >

        <div id="...">SomeContent</div>

        <span class="...">SomeText</span>

   </div>

</script>

What do you think?

 

[Ω Alisson]

I'm okay with that, if it is not slower than jquery.tmpl

[rpn]

Definitely useful features in the roadmap.

Seems like each would provide an alternative for common cases, but not necessarily replace current functionality.

I think that templates are still necessary/useful.  You can reuse a template in more than one location on your page.  Loading templates externally is also popular and that would be more difficult in the native version (you could load the template elements from a file, but then you need to know a lot about the page layout to understand where to place the elements).  One other thing nice about having the content in a script tag is that they are not actually DOM elements. With the control flow bindings, you have actual DOM elements that you will need to take care to hide before ko.applyBindings has done its work.

The extenders seem useful for the common format/deformat cases.  They don't quite replace returning your own dependentObservable when you want to add additional properties/methods or when the read/write code needs access to further state inside of the object.

Great stuff!

[Arxisos]

I didn't say that templates aren't useful anymore - sure they're useful because of reusabilty. I just wrote about using control flow bindings in templates, instead of native if-statements or something else :-)

[Roy Jacobs]

Excellent ideas! :)

To me, the 'extenders' concept is the most interesting. Are they executed in-order? For instance, in the throttle example, Is the target of the first extender (numeric) the second extender (throttle)? Where are the parameters stored in the above example (e.g. the 'true' for numeric and '2000' for throttle)? Or is this just a bit of pseudo-code?

I think this concept would also help with form validation. When submitting a form (e.g. after a "Save" button click), the code would be able to visit all observables, see if they have a 'validation' extender with some parameters (e.g. 'validation: { required: true }') and see if its contents are valid.

Roy

[Q]

Steve, thanks for all your hard work. The community appreciates it. I
think you are definitely onto something. The above ideas are cool. I
also wanted to suggest a unobtrusive way to define bindings on
elements. Thus
instead of
<select data-bind='options:datalist, value:viewmodel.valueholder' > </
select>
we can do
<select class='mydatalist' ></select> and then use script like this
$('mydatalist').databind({options: datalist, value:
viewmodel.valueholder});

I also think as the frawwork grows, we need more examples and live
apps showecase. I will be glad to contribute time to development of
apps to explore the many techniques a developer can use when building
web app with knockout.js.

> components, somewhat like Alisson has been showing here:http://groups.google.com/group/knockoutjs/browse_thread/thread/75dbfe...

>
> I'd love to see a standard KO plugin for doing that linking. I don't
> think it needs to tackle all the "single-page interface" details like
> loading external templates, but if it just handled the core
> observable<-->URL link, you can layer any form of navigation or
> template management on top of that.
>
> ============
>
> So, let me know what you think. The roadmap presently is:
>  * Implement and release 1.2.1, which should fix most of the

> outstanding issues athttps://github.com/SteveSanderson/knockout/issues

[Max Zelinski]

Extenders are definitely most interesting features right now for me.
The only big part which knockout lacks right now (from my point of
view) is validation infrastructure. I saw number of posts suggesting
to use jquery validation plugin together with knockout but I think
this is an adhoc way because validation should be a part of a model
and plus it's 1000 times easier to test the model using unit tests
this way.

> components, somewhat like Alisson has been showing here:http://groups.google.com/group/knockoutjs/browse_thread/thread/75dbfe...

>
> I'd love to see a standard KO plugin for doing that linking. I don't
> think it needs to tackle all the "single-page interface" details like
> loading external templates, but if it just handled the core
> observable<-->URL link, you can layer any form of navigation or
> template management on top of that.
>
> ============
>
> So, let me know what you think. The roadmap presently is:
>  * Implement and release 1.2.1, which should fix most of the

> outstanding issues athttps://github.com/SteveSanderson/knockout/issues

[Johan Nordberg]

I like it! A lot!

Some things that I would value is:

* Better documentation of the newer features and all the utils functions. 

* Script# support!

* Validation. Since most of us use MVC3 maybe jQuery Validation that would be nice, but it would be really nice if you could use ko bindings to tweak the validation and have an easy way of validating the viewModel. I'm thinking MVC ModelState. vm.IsValid(), vm.myprop.addModelError("You are baaaad!") and some custom validation like vm.myprop.validate(function(valueAccessor) { .... });

* Native support for jQuery UI. We have some nice custom bindings, but it would be nice to have it them as a official plugin and optimized for each widget.

// Johan

(How long does it take before ko is part of a new MVC project template in Visual Studio? :)  )

[Max Zelinski]

Agree for MVC ModelState approach. I'm currently trying to find a way
how to add .addError functions to current 1.2 ko.observable. I'm not
sure whenever .isValid will be possible because it will require either
extending some base viewModel class (which I'm against) or to add such
method in ko.applyBindings which is also not a good idea. I see it
something like ko.utils.isModelValid

[Max Zelinski]

After looking at the code Steve already wrote the 'extenders' wont be
really suitable for validations because .extend actually calls every
extender right away and doesn't store them and each extender must
return either observable or dependentObservable. This means it wont be
possible walk through 'validation' extenders because this is not a
list of extenders but rather a chain.

I think validation infrastructure should be added in more explicit way
as it was done in WPF with IDataErrorInfo.

[Max Zelinski]

btw is it possible to add observableAssociativeArray in 1.3?

On May 4, 1:57 pm, "st...@codeville.net" <fla...@gmail.com> wrote:

> components, somewhat like Alisson has been showing here:http://groups.google.com/group/knockoutjs/browse_thread/thread/75dbfe...

>
> I'd love to see a standard KO plugin for doing that linking. I don't
> think it needs to tackle all the "single-page interface" details like
> loading external templates, but if it just handled the core
> observable<-->URL link, you can layer any form of navigation or
> template management on top of that.
>
> ============
>
> So, let me know what you think. The roadmap presently is:
>  * Implement and release 1.2.1, which should fix most of the

> outstanding issues athttps://github.com/SteveSanderson/knockout/issues

[Q]

Hope we refrain from making decisions because "most of us use
MVC3" (and i assume you are talking of asp.net mvc 3). Building a
clients side framework should be generic enough to be applicable to
any backend/server side solution. Lets not inject specific server side
dependencies onto KO to make it more welcoming to others. if jquery
come with dependencies on the server-side, it wouldn't have been this
popular. KO could possible be even used in Nodes.js and more. I will
encourage keeping KO independent of any server side tech.

[Roy Jacobs]

I agree, I would also prefer to have validation in a separate plugin that makes use of, say, the extender functionality, instead of it being an explicit feature.

Roy

[emmanu...@gmail.com]

Hi, I just stumbled on a "could be nice" feature while working with jquery validation with knockout. Validation is key and looks like there is a lot of talk about it. In one of your response to a validation question, you suggeste creating a custom binding extending the value binding to add validation which was great. What would also be nice if the bind extension is passed a parameter called direction which the developer can use in the binding update function to decide how if handle the update depending on the direction of the binding. Direction "element-to-model" or "model-to-element". Just a suggestion.

[Johan Nordberg]

I'm not talking about dependencies to any server technology. I'm just saying ASP.NET MVC as example of nice and clean validation.

Just like KO today use jQuery Tmpl as the default template library it could use jQuery Validation as the default validation library. Have another favorite? No problem.

This way, KO don't have it's own validation, but in from developer point of view it just works. 

[Max Zelinski]

I think that validation should be attached to view model fields instead of UI inputs because it's much easier to test view model and this is a classic MVVM approach.

I've started drawing validation plugin on my own for KO that adds validation to view model. You can see it here http://jsfiddle.net/maxzelinski/GpTP3/

[Ω Alisson]

Being there too and gave up because once you have a big form you'll be bitten by performance issues AKA "this script is running too long"

[Max Zelinski]

How big your form was? I think it's always possible to speed up any solution just knowing where is the bottle neck :) My spike is a very dirty one - but once I will have time I'm going to wrap it in perf tests. 

I've been on the other side of the barricade with jquery validation and testing it was not pretty.

[Ω Alisson]

Something like 20 elements and I was using dependentObservable logic validating every required field to enable the save button.

[Max Zelinski]

Hm, interesting scenario. Were those 20 field had only required validation or something more complex?

As I understood dependentObservable on it's own can add a very big perf drawback because on every call KO resubscribe all dependent fields.

On Friday, May 13, 2011 5:04:12 PM UTC+4, thelinuxlich wrote:

Something like 20 elements and I was using dependentObservable logic validating every required field to enable the save button.

On Fri, May 13, 2011 at 10:01 AM, Max Zelinski <max.ze...@gmail.com> wrote:

How big your form was? I think it's always possible to speed up any solution just knowing where is the bottle neck :) My spike is a very dirty one - but once I will have time I'm going to wrap it in perf tests. 

I've been on the other side of the barricade with jquery validation and testing it was not pretty.

On Friday, May 13, 2011 4:54:36 PM UTC+4, thelinuxlich wrote:

Being there too and gave up because once you have a big form you'll be bitten by performance issues AKA "this script is running too long"

[Ω Alisson]

Required, number, date and time validations by regex

[Christoph Burgdorf]

I'm going out on a limb and say "let's integrate RxJS in favor for reinventing the wheel". Have a look at the RxJS/Ko bridge that I put together in just a few minutes. This comes with great power.

See in this example how I throttle an incoming stream coming from a input box, filter out duplicates, query a wikipedia service with the given term and avoid out of order results by using the Switch operator.

https://github.com/cburgdorf/Knockout-Rx/blob/master/app/App.ViewModels.SearchViewModel.js

It works like a charm

[Ω Alisson]

I fail to see the benefits of Rx integration

[Christoph Burgdorf]

Well, just have a look at my example. How would you write this without
Rx at the moment? The planned extenders (like throttle) are nice but
Rx comes with a lot of powerful operators *already* at hand.

> >https://github.com/cburgdorf/Knockout-Rx/blob/master/app/App.ViewMode...

[Jeff Sheldon]

You'll have to excuse my ignorance.  I'm getting the hang of using Knockout, but there are still quite a few things left to learn.

 

With that said, I don't know if this would help others, or if it's already in place or not.   But the ability to set some defaults or assumptions globally would be kind of nice.  

 

I think the best example I have is the ability to globally say:  By Default use a optionsText value of "Display" and an optionsValue value of "Value" unless I state otherwise.

 

That way, if I'm consistent in my ViewModel naming for the values I put in the "options" attribute, then I'm done.   I can't really think of anywhere else this kind of "Global" thing could be used, but I thought I'd throw it out there in case anyone else has an ideas.

[Steven Sanderson]

Hi Chris

Nice work with integrating Rx! Having spent a lot of time using RxJs last year on a big project, I am pretty familiar with the benefits it adds. Also, Matthew Podwysocki (the creator of RxJs) gave a talk on Knockout.js to the DC Alt.NET meetup this week, so this shows there are links back in the opposite direction too. 

What you're doing looks neat, and I'm sure there will be plenty of applications that would benefit from it. Hopefully with Knockout 1.3's extenders, some of those benefits (e.g., throttling, and the distinct-until-changed behavior) will be native to KO anyway and not require an additional library, and the KO 1.3 extenders will also make it easier for you to link KO and Rx together more elegantly.

Thanks for letting us know about this!

Steve

2011/5/25 Christoph Burgdorf <christoph...@googlemail.com>

[Michael Stum]

> Inline templates
> ===========
> The much-requested feature!

I second that. At the moment I'm using my server side code to output
all my templates (which I keep as separate .tmpl.html files) into
script tags, but since jquery-tmpl supports templates from strings I
would love to have a good way for inline templates, or even for
external templates (that are then fetched, e.g. as shown by Dave Ward
at http://encosia.com/2010/10/05/using-external-templates-with-jquery-templates/
)

> Extenders
> =======
> Often, people want to modify the behavior of an observable. For
> example, you might want to ensure it only holds a numeric value.

This reminds me a little bit of the column parsers that the
TableSorter plugin uses: http://tablesorter.com/docs/example-parsers.html
I really like this as my markup is kept clean while still centralizing
the code. Arguably this is a little bit different as this would change
the behavior of e.g. an HTML Input rather than the JavaScript model.

> For example, you'll be able to initialise an observable like this:
>
> var viewModel = {
>    myValue : ko.observable(0).extend({ numeric: true })
>
> };

I don't like the Syntax though, it seems overly verbose. Is it
possible to have an overload or separate function that takes an object
as the first parameter?

var viewModel = {
myUnconstrainedValue: ko.observable("Initial Value"),
// have some pre-built in?
myNumericValue: ko.observable(ko.observableConstraints.numeric,
"Initial Value"),
// not sure if I really like that, just an idea. Might clutter up
the public surface a bit too much
myFactoryGeneratedNumericValue: ko.numericObservable("Initial
Value"),
// The idea would be to have read/write encapsulated around a
parameter that's passed in to keep the custom code concise
myCustomValue: ko.observable({ read: function(val) { return val;},
write: function(val) { if (val <0 || val >10) return -1; else return
val; }, "Initial Value");
}

Just tossing ideas, I just don't like having to call .extend on the
initial creation.

One other feature I would love to see is built-in support for multiple
view models (something the namespace plugin already provides) and
maybe something more for parent/child views, but I think inline
templates can tackle this.

Great Work!

[Rushi Desai]

Some sort of data store support for querying and loading data and
saving changesets would be a nice addition to simplify working with
data stored server-side and/or localStorage. SproutCore has a pretty
decent model. Also, I like the RIA services prescriptive pattern which
works great for MVVM apps.

[Andrew Booth]

Hi Rushi

http://amplifyjs.com/api/store/

http://datajs.codeplex.com/wikipage?title=datajs%20store%20API&referringTitle=Using%20Stores

In reference to client side storage and aspects of changeset tracking, have you experimented with either of the above libraries, used alongside Knockout? I suppose a KO 1.3 extender for an observableArray might be an interesting experiment to see what is possible.

Andy

[emmanu...@gmail.com]

Steve, will it be possible to introduce unobtrusive binding such as the follow in future versions
var Model ={ myvalue: observable(), listitems: observableArray([..])};
ko.dom('.input').databind({ click: function(){ ..}, value: myvalue, visible: myvalue() != null },Model)
ko.dom('.list').databind({ template: '#listtmpl', foreach: listitems }, Model)

Thanks for your hard work. KO is definitely one of the best js library I have ever used.

[noel.a...@hotmail.com]

Hi, I've been playing around with KO just a couple of days now, so maybe I'm missing something.

The problem is to do with initialising the state of the view model. Once the VM is bound to the DOM KO sets the value of any bound elements to the value of the corresponding property on the VM. That means the initial value of the DOM element must exist in the VM. 

This issue is raised on SO and R.P. Niemeyer suggests two possible solutions.1. Initialise the VM via a JS variable:

• On the server controller method add the state to the ViewBag as a JSON object.
• On the ASP.Net page deserialise the JSON object into a JS variable:
  

  <script type="text/javascript">
      var initialData = <%= new JavaScriptSerializer().Serialize(Model) %>;
  </script>
  

• Initialise the state of the VM from this variable:
  

  var viewModel = {
      gifts : ko.observableArray(initialData)
  };
  

2. Initialise the VM from the DOM after page load

• On page load, initialise var intialData by running some JQ on the DOM.
• Pass the initial data to the VM.
• Now call applyBindings

The problem with these solutions is that they expect the javascript to be embedded in the HTML. Ideally, the script tags should only reference external .js files, less obtrusively.

The workflow I'm seeing is: ASP.Net (or similar) creates initial state of page >> KO binds DOM elements to view model >> view model properties initialised from values in DOM >> two-way binding carries on as normal.

I've tried a few things but cannot get KO to read the initial value of the VM property from the DOM element. I feel the problem is to do with the fact that a single ko.observable can be bound to multiple DOM elements, hence we don't know which value should be used in this context.

If in ko.observable(initialvalue) the parameter initialvalue were null then we could set value of the corresponding VM property by reading the existing value from the bound DOM element, and if there are multiple elements then perhaps we have an erorr.

[noel.a...@hotmail.com]

I should have said that with the second approach there is no embedded javascript in the HTML, but what I'm trying to do is to avoid the extra work of running the JQuery in order to initialise the view model.

[rpn]

I'm not sure if this is exactly what you are getting at, but a few times I have suggested something like a "valueWithInit" custom binding that initializes the view model value from the existing DOM structure.  Here is one thread: https://groups.google.com/d/topic/knockoutjs/m4SECD6UFl8/discussion

Here is a sample: http://jsfiddle.net/rniemeyer/BnDh6/

[noel.a...@hotmail.com]

Thanks, RPN, the custom binding is working as expected.

However, it doesn't seem to be the most efficient way to deal with this.

In the sense that we have the following:

• The bound values are first written to the VM from the DOM.
• But this triggers the ko.observable change event (on the VM).
• And so the VM value is then written back to the DOM via an Update callback.

I think my use case of initialising the VM via the DOM is a common one, and should be optimal (i.e. handled organically by KO) - especially considering the case of hundreds of DOM elements bound through this mechanism.

Let me know if I missed something or if there is a way to stop the update callback from triggering unnecessarily.

Thanks!

[rpn]

For any binding, the init and update functions are both called on initialization.  The update function of the value binding does make an attempt to see if the value has actually changed or not.  So, in my fiddle, it is never actually written back to the DOM, just checked to see if it should be written.