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.bb, a.cc, 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.