Idea for having 3rd parameter for go.Binding

In go.Binding conversion functions, there are 2 parameters for the functions, first parameter is the supplied property value argument, and the second parameter would be Shape/Part/Node object, etc., I was thinking the 3rd parameter could ALWAYS be supplied with the Node’s “data” object always. That way, a function can use both the “data” object and "property string reference’ object as reference, in situations where the coder needs both references at hand (eg. sometimes, the “reference” object might be null or lack another nested property value…so one can use the “data” object value instead, etc.)

Performance implications with empty src property name?

As mentioned in the manual for go.Binding

An empty string argument for the sourceprop parameter indicates that the whole data object should be passed to the toLocation function, rather than the value of some property of that data. The return value is used as the new value for the Part.location property. In almost all cases the second argument is not used. For efficiency reasons you should try to avoid using an empty source property name.

Now, i guess "efficiency " reasons is that I infer that when updateTargetBindings is called or bindings are updated, bindings with empty source property names are ALWAYS processed, regardless of what src property is supplied, right? Thus, having lots of these empty src property bindings may clog performance, issit?

I doubt GOJS has any good binding techniques to actually analyse the function expression and determine the property chain dependencies? Is it possible to pass a property chain array of sorts, etc. to reflect the set of nested properties? Most binding frameworks have this sort of functionality (dot syntax, expressions, etc.), but the way GOJS does data-binding, is very basic. eg. My ideal binding dependency checking approach would be tree-based, so updateTargetBindings for “a”, would update all descendent target bindings under it for ",, a.dd, a.dd.kk, etc.). But I guess, that would need a separate toolset (possibly a virtual dom tree of all these properties and directives to call GOJS updateTargetBindings…), i guess?

Anyway, having a 3rd parameter that points to “data” always might be handy in some situations where root “data” access is still required but I want to avoid empty “src” property name as well.

I see you have thought about this a good deal. I appreciate that.

For source-to-target conversion functions, you can access the whole data object via the second argument. But we don’t recommend this in general because the dependencies are misleadingly assumed to be just on the one named source property.

You might be interested in this sample: It basically puts all of the data properties on a sub-object of the It does not support property paths. It still requires explicit notification when subproperties are modified.

The (sub)properties are on an Object that is the value of a data property, so for example:

    { "key": 1, "details": { "text": "Hello", "color": "red" } }

Instead of constructing a normal Binding, one uses a helper function:

    makeSubBinding("stroke", "color")

Although those Bindings assume all of the subproperties are under the “details” property, I think that could be generalized if you cared to have a variable number of properties where subproperties were located, for example by using a dotted property path.

I should also say that people do not often ask for property paths as binding sources. Perhaps because there are so many alternative mechanisms for getting at “subproperties”.

Another one that neither of us has mentioned so far is by implementing custom getters and setters. That’s not as general or as convenient as what you’ve done in Go.Binding and nested properties, but it’s simple and fast.