You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To avoid even further data massaging, it would be cool to have "virtual" attributes for id, label, children, filter by allowing function instead of attribute names.
My prime usecase is a translation array at the label property,
so my data looks like this
/** * Get the label for `node` * * Abstracts away the need to know the actual label attribute in * templates. * * @param {Object} node A tree node * @return {String} The node label */
trvw.label = function(node) {
+++ return node[localOpts.labelAttribute()]; // Do it conditionally on function
--- return node[localOpts.labelAttribute];
};
And it still should be filterable. So something similar required there too.
All code snippets are only to illustrate my point, they certainly don't attempt to show way to do it.
Regards.
The text was updated successfully, but these errors were encountered:
I think this is something we could support in version 1 by leaving those things as variables instead of functions and just watching for updates. Or perhaps better, just re-flattening our local options whenever they're asked for.
Happy to investigate when available but we'd be certainly open to a PR that doesn't break backwards compatibility.
To avoid even further data massaging, it would be cool to have "virtual" attributes for id, label, children, filter by allowing function instead of attribute names.
My prime usecase is a translation array at the
label
property,so my data looks like this
With API like this
And it still should be filterable. So something similar required there too.
All code snippets are only to illustrate my point, they certainly don't attempt to show way to do it.
Regards.
The text was updated successfully, but these errors were encountered: