Add optional callback for when view-binding function completed

[jacobemcken]

We discussed this here: https://groups.google.com/forum/#!msg/enfocus/rZTL-GOrZtM/upolupLhF9QJ

I suspect you would want to add a callback key in the options map for the bind-form function. But do you want to add an extra argument or change the mapping argument to an options map for the function bind-view?

[ckirkendall]

I think we should add it to bind-form and bind-input. Since the user is providing the render-view function for bind-view and could include any call back functionality in that, it seems a bit redundant.

On Wed, Mar 5, 2014 at 3:29 AM, Jacob Emcken [email protected]:

We discussed this here: https://groups.google.com/forum/#!msg/enfocus/rZTL-GOrZtM/upolupLhF9QJ

I suspect you would want to add a callback key in the options map for the bind-form function. But do you want to add an extra argument or change the mapping argument to an options map for the function bind-view?

Reply to this email directly or view it on GitHubhttps://github.com/ckirkendall/enfocus/issues/90 .

[jacobemcken]

Okay... I'll try conjure something up and send something later today.

[jacobemcken]

I think using the render-view function for a container to the "callback" code in bind-view is a problem because you don't have access the value before and after. This means that I can't see if it is ie. the street name or the zip code that has changed.

[ckirkendall]

hmmm, going to have to think about this one. You stated you could fire the event from a watcher on the DOM. This seems like how I would want to do it instead of letting the dom drive anything. Why are you firing the change event vs just calling the code the change event calls with the watcher? The more I look at this I think its might be a bad idea to have changes in the dom drive stuff when view bindings are attached because the idea of view bindings is I only have to work with the app state. I need to think about this some more.

[jacobemcken]

I'm using a generic jQuery plugin which hooks on to a form and among other things listen for changes to the zip code to lookup the matching city (the city input field is readonly). Now I want to use the two way binding from ClojureScript to populate the form, but I also want it to automatically look up the city. So you could say the problem is that I don't want to maintain the functionalty from the jQuery plugin in ClojureScript as well (it uses jQuery UI auto complete heavily). I understand your concern... let me know if you come up with something :)

[jacobemcken]

I just re-read your answer and thought I needed to elaborate on the watcher. The watcher wasn't place on the DOM or watching the DOM. I was just a normal atom watcher attached to the same atom that the bind-form uses. I had hoped that depending on the "attach watch"-order I could trigger the change event after the DOM update. But the DOM update seem to be asynchronously, so no matter if my watcher is attached before or after the bind-form my manually triggered change event would fire before the form input fields had been updated with the new values, thus causing the change event to use the old value of the input field.