Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

independent binding handlers #1

Closed
mbest opened this Issue · 8 comments

2 participants

@mbest
Owner

An element can include multiple bindings. Often an element will include a combination of lightweight and heavyweight bindings. The former include visible, css, enable, attr. The latter include template, options, html. Currently the dependencies of all bindings for an element are linked; thus an update to the dependency for one binding will update all bindings. This negatively affects performance when only a lightweight binding needed updating, but the heavyweight binding was also updated.

I propose that bindings should be independent of each other unless there's a specific dependency specified (for example, value and selectedOptions are dependent on options).

@mbest
Owner

Bindings can make themselves run independently (mostly) of other bindings by creating their own dependentObservable to wrap their actions or using the subscribe function. See the async binding I created as an example of this. Within the Knockout core, the template binding also does this (but it's less independent since it's within its update function).

With the change proposed in this issue, the above method would be unnecessary, and should be discouraged.

@mbest mbest was assigned
@mbest mbest referenced this issue from a commit
@SteveSanderson SteveSanderson Replace automatic inheritance of all bindingContext properties with n…
…ew $parentContext variable

Benefit #1: Can reach custom properties on *all* ancestor contexts, and are not limited to those that haven't been overwritten
(e.g., if we had $index, would now be able to reach all ancestor $index values, not just the closest one)
Benefit #2: Allows discrimination between properties at the current level and properties at the parent level, which
is good because not all custom properties may make sense to inherit.
ab8087e
@gilesbradshaw

Currently applyBindingsToNodeInternal runs a dependentObservable which serves to init and update all bindings. This gets re run when ever any observable used by a binding changes.

So what you are suggesting is running a dependentObservable separately for each binding? (or maybe running dependent observables inside the original dependent observable).

@mbest
Owner

So what you are suggesting is running a dependentObservable separately for each binding?

That's part of it. An equally important part is that parsing the binding string shouldn't access any observables. They should be accessed only within the binding handler. I've already implemented these changes in my "smart-binding" branch and you're welcome to take a look at what I've done.

@gilesbradshaw

Thanks - could you point to a discussion of the different types of bindings ie

0 : unorderedBindings
1 : contentSetBindings
2 : contentBindBinding
3 : contentUpdateBindings

@mbest
Owner

could you point to a discussion of the different types of bindings

I've described it in the readme. Do you have any specific questions?

@gilesbradshaw

Thank you for that. I saw something somewhere else but that is brilliant.

Alongside independent bindings there should be multiple independent binding providers. Each binding provider should be configurable with a namespace for binding attribute, virtual element tag name, templating (or even if method of providing bindings &c).

This would allow interdependent binding systems to operate in an application.

This would make knockout much more powerful.

Adding a new binding provider (configured with a different binding attribute and virtual element tag ``ko.bindingProvider["instance"]..push (new ko.bindingProvider({name:'new', bindingAttribute: 'data-bind-meta', virtualElementTag: 'ko-meta'})

Your bindings are not independent bindings they are interdependent bindings.

I got as far by namespacing binding providers so they have their own binding attributes and virtual element tags and maintain their own binding contexts.

One of the ways that this could be quite powerful is allowing one binding provider to produce bindings from one binding context for another binding provider in another context.

See this example where meta data is used to enumerate bindings to be applied in the context of the data it is displaying. This might be pertinent in the context of data services that supply their own meta data.

http://jsfiddle.net/GilesBradshaw/YcK7V/

In this example one binding provider produces bindings (using the attr binding) that another binding provider implements. However it relies on the order that bindings are applied to work.

What in need to do is make my bindings interdependent (as you have) so updating one will trigger the update of another.

I'm sending you a pull request of some work I am doing to leverage your independent (interdependent) bindings to facilitate interpendent binding providers. I am wondering if these ideas could be combined in a future version of knockout.

@mbest
Owner

@GilesBradshaw - Have you checked out my repeat binding? I think it will do what you want without having to use multiple binding providers. Example: http://jsfiddle.net/mbest/YcK7V/21/

If I do include support for multiple binding providers in my fork, I would probably have them share the same binding context (unlike what you have done) so that each element only has one context.

@gilesbradshaw

Hi Michael - thanks I will have a look at that it certainly seems to do what I was thinking of.

I am displaying lots of different types and am trying to make it as generic as possible at the moment I am using Razor to stipulate what columns are to be displayed using reflection. I wanted to move this function to the client.

@mbest mbest closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.