Delayed value on inputs about rivets HOT 18 CLOSED

Would triggering a change on the input element on keyup be an acceptable solution for this? That way you can keep using the standard data-value binding declarations.

<input data-value="item.name">

Trigger a "change" on keyup for all input elements that bind their value to the item.

$(":input[data-value^=item]").keyup ->
  $(this).trigger "change"

from rivets.

This would be easy to implement as a configuration option, but then if you want certain inputs to publish on change and some to publish on keyup, then it gets a bit trickier.

Perhaps in addition to data-value there could be data-value-[event], which would publish on any arbitrary event (keyup|keydown|keypress|change)?

from rivets.

Solution looks good to me - thanks

from rivets.

was this implemented? either way, is there a working example of how you would do this in rivets? I'm using watch.js if that matters.

from rivets.

@ImaginaryDevelopment Thinking about it now, my suggestion to trigger change events on keyup is not a very elegant solution. You'd be better off using a custom binder for live inputs until a more formal solution is in place. Here's a simple one that I use often without issues (the input event is IE9+, so just use keyup instead if you're not only targeting IE9+ and modern WebKit).

rivets.binders.input = {
  publishes: true,
  routine: rivets.binders.value.routine,
  bind: function(el) {
    el.addEventListener('input', this.publish)
  },
  unbind: function(el) {
    el.removeEventListener('input', this.publish)
  }
}

And then in your view, instead of using data-value, just use data-input.

Regarding a solution to the actual problem, the ability to pass in flags to binding declarations is probably the closest candidate so far as to what you can expect as a real solution. Would probably work something like the following.

<input data-value="item.name --on input">

Or as a boolean/simple flag.

<input data-value="item.name --live">

Still working out the details on this.

from rivets.

Re-opening this issue, as it's clearly not addressed yet.

from rivets.

I've solved this by introducing another data-attribute: data-event="keyup" for instance. If this attribute is given the binder takes it as event-name instead of the default.

If you adjust your adapter accordingly, this is especially cool when adding dom elements to the models-object. This way I can directly react on dom events. For instance: I have this input field, that displays a magnifier-icon or a cross-icon depending on the input's value.

<input data-event="keyup focus" type="text">
<label data-class-icon-search="input.value | false"
    data-class-icon-cross-3="input.value | true"></label>

That's it! 😄

from rivets.

@jhnns Cool use case! That's doc-worthy

from rivets.

Any update on this?

from rivets.

any update on this?

from rivets.

I'm curious if there has been any change with this as well.

from rivets.

This is also an issue when the browser doesn't trigger a change event. Safari autocomplete for inputs doesn't.

Is there a workaround?

from rivets.

Having an issue with autocomplete as well - any update on this?

from rivets.

In the latest rivets 0.8.1.

The three binders that publish, where published : true in the binder listen as follows:

The rv-checked / rv-unchecked binders listen for 'change' https://github.com/mikeric/rivets/blob/master/src/binders.coffee#L37

The rv-value binder listens for the 'input' event on input elements, and the 'change' event on radio inputs.
https://github.com/mikeric/rivets/blob/master/src/binders.coffee#L75

@gooftroop Can you describe your issue in more detail? Is the input event not triggering autocomplete?

from rivets.

I am bit confused as to how to apply formatters for form fields if you can't control when the timing on the binding.

For instance, I have a simple formatter that correctly formats a date in a text input field when the form appears.

rivets.formatters.datetime = {
    read: function (value) {
        if (moment(value).isValid()) {
            return moment(value).format('MM/DD/YYYY hh:mm A')
        } else {
            return value;
        }
    }
}

Everytime a character is changed its attempting to format the result as a date making it impossible to actually edit the value (you get garbled results since its formatting partial entries). It seems to me that the formatter should only attempt to format the field when the user finishes editing the value (lost focus)?

Some guidance would be appreciated. It seems that I do not understand how these formatters should be applied with the way the binder works.

from rivets.

@Bluejay47 Here is a value-on-blur binder:

rivets.binders['value-on-blur'] = {
    publishes: true,
    priority: 2000,
    bind: function(el) {
        this.event = 'blur';
        rivets._.Util.bindEvent(el, this.event, this.publish);
    },
    unbind : function() {
        rivets.binders.value.unbind.apply(this, arguments);
    },
    routine : function() {
        rivets.binders.value.routine.apply(this, arguments);
    }
}

You can use it like:

<input rv-value-on-blur='model.something'/>

This will only run the binders routine when the input has been blurred. The formatters will run after that.

Here is an example, http://jsfiddle.net/p5482deg/1/ , from #473 that demonstrates your issue exactly. Notice that the 'formatterThatMakesTextCamelCase' only runs once the input has been blurred.

As far as guidance goes, (my opinions)
It seems to me that the best way to go is get used to writing your own binders and formatters, when the originals don't de EXACTLY what you need, feel free to make new ones. Don't be afraid to extend the functionality of the default ones. Rivets source does this quite often, in the case of the rv-unless binder and the { } interpolation. I highly recommend spending some time reading rivets source code. The coffee script makes it difficult to understand, but in general it is very good. I have not used the components feature very much, but with custom adapters, binders, and formatters I have found I can get pretty damn far with no other dependencies.

from rivets.

@Duder-onomy Currently seeing the this issue on FF 34 CentOS 6 (my other devs are using newer browsers and have not seen this issue, but I don't think anyones tested for it yet). Updating my previous comment too as well - the dev sees this on a page refresh and not an autocomplete action on an input. I believe in FF this is also consider an autocomplete event (suggested fix is autocomplete=off) and strikes me as a race issue between the values being placed in the input box and rivets binding. I'm wondering if there has been any discussion on retroactively publishing data if said data existed when bound?

from rivets.

Closing this for now as it seems to have been resolved as far as possible. Custom binders are the way to go.

from rivets.