Microsoft’s Proposal for Data Linking in jQuery. Feedback Requested.
Microsoft has submitted it’s second proposal to the jQuery Project outlining a plugin that allows properties within objects to be linked to each other. Termed “data linking”, the new plugin would allow changes made to a property of one object to effect a change on the property of a secondary object. The plugin leverages jQuery’s “special events” API to create a new event that will trigger when a change occurs on a bound object property. This would allow a developer to link properties in the following way:
var person = {};
$(“#name”).linkTo(“val”, person, “name”);
$(“#name”).val(“foo”);
alert(person.name); // foo
// … user changes value …
alert(person.name); // user typed value
The proposal has been submitted via the jQuery forums and Microsoft is actively soliciting community feedback:
http://forum.jquery.com/topic/proposal-for-adding-data-linking-to-jquery
A prototype of the data linking is available for review via Github:
http://github.com/nje/jquery-datalink
We’re pleased to see Microsoft’s continued contribution to our open source community and ask that you provide feedback in guiding this effort along.
This is great. Will definitely give it a try
Wow, I was just thinking how useful something like this would be on a project I’m working on right now. Well done, Microsoft.
Well, there’s another plugin I wrote that I can throw away. :]
Wow… linkBoth makes me a happy camper! Andy, I’m with you – I can throw away a plugin I wrote now. This one is much better than the junk I wrote to accomplish something similar.
How do people see this being used? Can it take functions instead of a property to call back? That might be useful for hooking up ajax requests, but a change event will do that as well.
I typically try to avoid state being kept in multiple places and this seems to encourage it. But it could help performance as one wouldn’t have to look up these values in the dom.
It touches on a potentially useful idea of sending special events for the jQuery dom modifiers.
I like the idea, and the syntax works for me – I can definitely see the usefulness, and would be happy to put it to use immediately on a current project or two — but wonder why part of the core library as opposed to a Microsoft-hosted jQuery plugin?
Excellent addition, this will definitely come in handy in development.
This would be indeed very helpful.
Please keep the good work…
I think I’d support this extension.
Without the ability to define ConvertFn’s for it I’d be less interested, but with that too, it looks very useful.
My only concern would be whether it added excessive load in it’s monitoring of arrays etc.
The only change I’d specifically like is the ability to directly provide the converter code, rather than having to register a converter function. For example…
var person = {};
$(“#name”).linkTo({
sourceAttr: “val”,
target: person,
targetAttr: “favoriteColor”,
converter: function(value, settings) {
return settings.map[ value ] || value;
},
map: { red: “#FF0000”, blue: “#0000FF” }
});
$(“#name”).val(“red”);
alert(person.age); // #FF0000
Otherwise, I think I like it.
@Justin Meyer
Simple example would be an AJAX call using JSON. Instead of having to process values on submit, imagine your data (JSON object) changing as the form changes (as user enters them). There, no need to process form data into JSON.
(Sure you can just serialise the form, but hey you won’t even have to serialise once you hook form inputs into your data (JSON) object)
Nice thinking. It would be nice to have that feature particularly in a MVC application using AJAX.
What about an unLink (or removeLink) method? Also, getLinks could be useful.
sounds perfect for View = View model binding!
I have quite a few projects built over the past couple of years I could have used this on.
I would like to see the possibility of passing in a form or perhaps other jQuery identifier and have the plugin match all existing fields. Assuming my data object and html form both contain properties/fields with same names then have the entire form synchronized to the data object.
David,
Thats was the use case I expected, but in my opinion, seializing the form is a better method. You don’t have state 2 places, and you don’t have this object hanging around. However it’s declaritive nature is easier to understand and less code (which is why people love bound variables).
@Keith – You can in fact pass a function directly for the converter, something a few other people have mentioned as well.
@Dave Hulbert – Unlink certainly _should_ be available, but isn’t implemented in the prototype.
Of course, one of the great things about github is how social it is, feel free to fork and incorporate your ideas everyone!
This sounds great to me. Think about uses other than with forms… say you have an interface with drag & drop and resizable elements. You could bind this to position and easily use it to store the current configuration and post that back to the server so you can save it for the next time the user comes back.
Would save a potentially long walk through the dom gathering all the data when it’s time to save.
On forms with several fields, this will be a boon. The linking between conditional fields will become much more cleaner.
I like it – I haven’t downloaded the code yet and maybe it’s there, but I’d like for the third parameter to optionally accept a function for more complicated binding scenarios. For example:
$(“#name”).linkTo(“val”, person, function() {
return person.firstName + ‘ ‘ + person.lastName;
});
I guess serialising vs data-linking was kind of a bad use case, since serialising the form is a good choice anyway.
However, as you said, there will be 2 data objects that come from 1 source. So theoretically, if all goes well, it’s actually 1 data state, with multiple access points that come in different format/forms.
To take the form example further (I hope I am not building another use case here) – imagine validating the form on the client side. Instead of a whole bunch of $(‘#id’), $(‘.class’) calls, we could data-link the form inputs into an object, and have validate() function validate the object.
In short: from one data source (therefore 1 data state), we can draw on multiple data objects in different forms (in this case, a javascript object) and perform operations differently depending on the context.
I would much rather data-link form inputs into an object, then validate the object than validating the form input(s) directly.
In the end, all we’re trying to do here is take the form, validate it and submit it. And the way we take the form, vaidate the form and submit the form come in many different ways. It could be natrual submit, ajax call or however way people do it. Having the flexibility of accessing the form data in a different format is advantages at the very least I would say.
Or you can choose not to use the data-linking ;) The question should be:
Is data-linking important enough to be included in the jQuery core? I would certainly say so, because most of the jQuery work I do is around data-binding and validating anyway!
Something’s bothered me about this proposal since Rey Bango announced it on Twitter the other day. I like the idea of data linking, but I find the proposed syntax un-jQuery-ish. The point of the library is to abstract away complexity where possible, but the method signature forces me to consider how I’m going to be updating the data later in order to work.
Is there a reason the call couldn’t look something like the following (where “obj” is a jQuery object or, perhaps even a reference to a DOM element’s attribute, and “var” is any valid, in-scope variable reference):
$.link(, [, ]);
I haven’t tried to code this up, so I don’t know how difficult it would be to implement, but it seems more in the spirit of the library to make it simple to link up whatever the developer needs linked up. E.g., why not let me link a text input to a select list or link 2 variables to each other?
Let me know if I’m off-base or missing something obvious!
Oy, let me try the method signature again:
$.link( obj|var , obj|var [, pre-processor function ]);
I feel like the name “linkTo” is not intuitive for a function of 3 arguments.
-> therefore we could either change the number of arguments, change the name, or both.
The key is finding the most intuitive, simple, and jQuery-ish way to do it.
I don’t know what the attr() function is capable of at this point, but this might be a cool way to do it.
$(“#name”).attr(“val”).linkTo(person.attr(“name”) [, pre-processor function]);
Definitely will give it a try, the idea itself is awesome
What about an unLink (or removeLink) method? Also, getLinks could be useful.
Please, Get Microsoft out of our lovely $ code!
They are known to kill every good thing!
I am sure many many developers will miss jQuery’s.
Web developers have to spend almost 40% of there time to debug and optimize for our lovely IE.
In the latest keynote of IE9 they made it sound like “they” are the ones who understand the developers by offering new tools and setting the tone of web development, We all know that if not for IE the web today would be way ahead! What do you think? they will change in one day?
John, Please reconsider your partnership with Microsoft!
What problem are we trying to solve? maintain an alias to a value stored in a form? introduce pointer-lookalikes in javascript/jquery?
It’s bad programing practice to keep two copies of one state. In the example, what happens if some code updates person.name?
If it’s just a plugin then simply release it and let people decide whether they want to use it, but there should be no impact on jquery as such.
I am curious about this “data” solution also. It needs some usability testing done on it IMO. It seems detached more than intuitive. A certain amount of training is required for any technology but it is like @Magnus said. What problem are you trying to solve? I love the data binding in Flex/Actionscript. If data binding is what you are after that is an ideal to shoot for. If data store is what you are after it seems disconnected. It is very easy to see what you did but the question again begs… is this data binding, data store or something else?
They are known to kill every good thing!
I am sure many many developers will miss jQuery’s.
Web developers have to spend almost 40% of there time to debug and optimize for our lovely IE.
@Adardesign: Well, I’m sure you also know that without MS and IE you wouldn’t have AJAX.
In fact, a lot of this discussion reminds me of something else that MS created along with the XmlHttp object. It was client side databind to xml “data islands”.
Basically, you can bind an XML object on the client side to a form, when a user updated the form, the xml fields bound to each input element will also be updated.
I remember using that to do validation on the XML instead of the form elements…
I find myself writing code different types of persistence code too often to ignore a feature like this, it could save time if it doesn’t cause performance issues.
Seems like a great idea, and really simple. Cant wait to see it make its way into JQuery
Should reduce coding and reduce prototyping time a lot.
http://www.javerter.com
Dave and Tony
Like Justin I fail to see how it ease form validation and such.
If you cache all your form elements, as you should, then you pretty much have the same thing as you have here apart that you have to use .val() to grab the value but you do a lot less than the plugin does.
Not only it has to bind on every form element to work but it will also need to collect the value for the form to be able to save it. Which is exactly what we would do if we loop through an object of cached elements and grab there value.
Using this plug-in for form validation will increase the memory usage as well as increase the number of function call and element created.
Good for some, but I wouldn’t say good for performance.
Adardesign, if it’s a good idea it doesn’t matter who proposed it. If its implementation saves time for developers, it deserves full attention. This is about being practical. Not *everything* M$ does is wrong. Besides, this proposal was brought out in the public for developer feedback.
“Microsoft” (its speakers, actually) stated many things and developers amuse themselves or get angry with, but noone can expect Microsoft to learn how to improve their ways if we simply block them out. Wouldn’t that be our own example of “monopoly”? In the open source world anyone should be able to propose features. Then it’s up to the developers if they will make it happen. The jQuery developers are reaching out here for feedback. This is as fair as it gets.
I fail to see how it’s useful and indeed think it’s a bad idea to try to maintain multiple copies of state’s like that. It looks like spaghetti all wrapped up into a plugin. I’d prefer it was kept out of the core. Unless somebody can refer us to some practical application of this where the alternative is worse: code up an example with and without this to show how this is useful.