Support parameterless binding syntax

[jonrimmer]

Custom bindings are often used to attach scripted behaviours to elements, particularly those created by templates. When used like this, there may be no need to supply parameters such as an observable to the binding. In these cases, it is usual to pass a placeholder parameter such as an empty string or a boolean to the binding:

<div data-bind="myImageGallery: true, visible: isGalleryVisible">
   ...
</div>

However, this is a little untidy, and it makes the code a little less comprehensible, because it is not obvious looking at the code that the parameter is not being used. It would be nice to be able to specify bindings without any parameters:

<div data-bind="myImageGallery, visible: isGalleryVisible">
   ...
</div>

[SteveSanderson]

Thanks for suggesting this Jon.

Right now I'm not 100% sure either way about this. Currently, bindings are always parseable as a JavaScript object literal, so having exceptions to that constraint loses a bit of the elegance, and could act as a breaking change for some kinds of extensiblity (e.g., custom binding providers). I'll leave the request open and marked as "Future" for now, and we can see if other community members have an opinion.

[mbest]

I like the idea. Already, Knockout modifies the binding string before it's converted to a Javascript object, adding quotes to the binding names, and adding writer functions. So it wouldn't be a big stretch for it to make other modifications.

[mbest]

I'm labeling this for inclusion in v2.2 with minor impact, based on changes required for #321.

[SteveSanderson]

Thanks for the suggestion. Personally I don't think, however, that it's going to be beneficial in the long run. Any future tooling would no longer be able to parse the bindings as JavaScript, plus if we move away from the standard constraints of JavaScript object literals, it will become very hard to decide which kinds of syntactical constructions should be allowed and which should not.

Allowing this would be similar to having CSS properties with no value, e g.:

.mySelector { color: red; hidden; } /* instead of display: none */

... or JavaScript object literals with keys implicitly mapping to undefined:

var x = { someProp: 123; anotherProp; }

These sorts of things aren't permitted, even though in some cases it would lead to less typing, as there are significant benefits in having only one pattern that rule formatting should follow. It's easier to learn and makes tooling easier to develop.

Since it's not causing any significant disadvantage to developers, I would suggest closing this proposal.

[rniemeyer]

My feeling is that the binding strings should be valid JavaScript object literals.

[mbest]

My feeling is that the binding strings should be valid JavaScript object literals.

As I mentioned in #233, we already allow binding strings that aren't valid Javascript (at least in some browsers) by adding quotes around the root-level keys before eval-ing.

[rniemeyer]

As I mentioned in #233, we already allow binding strings that aren't valid Javascript (at least in some browsers) by adding quotes around the root-level keys before eval-ing.

Seems a little different to me, as it is just certain browsers that have a problem with the keywords and people are usually attempting to write valid JavaScript in this case. Not a big deal though...

[mbest]

I've changed this to "future" instead of "v2.2". We can pick up this discussion again later.

[mbest]

This is now available in 3.0 (currently in development). If you specify a binding without a parameter, the binding is called with a parameter of undefined. Using the new preprocess functionality, any default value can be specified. Here is an example: http://jsfiddle.net/mbest/BcUN4/