Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blaze reactive variable in input value is not updating #1965

Closed
clubfest opened this issue Mar 27, 2014 · 10 comments
Closed

Blaze reactive variable in input value is not updating #1965

clubfest opened this issue Mar 27, 2014 · 10 comments

Comments

@clubfest
Copy link

@clubfest clubfest commented Mar 27, 2014

Below, the reactive variable greeting updates in the h1 but not in the input's value.

template:

<template name="hello">
  <h1>{{greeting}}</h1>
  <input type="button" value="{{greeting}}" />
</template>

js:

if (Meteor.isClient) {
  Template.hello.rendered = function() {
    Session.set('greeting', 'hi ')
  }
  Template.hello.greeting = function () {
    return Session.get('greeting');
  };

  Template.hello.events({
    'click input': function () {
      Session.set('greeting', Session.get('greeting') + 'bye ')
    }
  });
}
@avital
Copy link
Contributor

@avital avital commented Mar 27, 2014

Thanks for the report -- i've confirmed the bug.

It's due to our management of focused elements ("don't update the contents of an input element that's currently focused"). We should see if there's a reasonable way to resolve this (maybe relax that constraints for buttons?) but we're not going to block 0.8.0 on this.

Loading

@clubfest
Copy link
Author

@clubfest clubfest commented Mar 27, 2014

Actually, I was trying to do something with text input. I end up using jquery events to resolve it so it's not a problem.

Deps.autorun(function(){
  $(window).trigger('greetingChanged', Session.get('greeting'));
});

$(window).on('greetingChanged', function(){
  $('input').val(Session.get('greeting'));
});

Loading

@gartz
Copy link

@gartz gartz commented Mar 28, 2014

Same problem for me, but when I rollback to meteor 0.7.1 it start a annoying behavior, after it update the value, it re-focus the element selecting all the text, so you cant write a word, each keyup select all the text and the next will erase the value then only type the key pressed...

How can I remove and only install meteor 0.7.1 again, it was working fine for me...

Loading

@avital
Copy link
Contributor

@avital avital commented Mar 28, 2014

meteor update --release 0.7.1

On Thu, Mar 27, 2014 at 10:17 PM, Gabriel Reitz Giannattasio <
notifications@github.com> wrote:

Same problem for me, but when I rollback to meteor 0.7.1 it start a
annoying behavior, after it update the value, it re-focus the element
selecting all the text, so you cant write a word, each keyup select all the
text and the next will erase the value then only type the key pressed...

How can I remove and only install meteor 0.7.1 again, it was working fine
for me...

Reply to this email directly or view it on GitHubhttps://github.com//issues/1965#issuecomment-38889535
.

Loading

@gartz
Copy link

@gartz gartz commented Mar 28, 2014

I've done that, but the bug persist :(
in the production server is ok, but in the development with same code isn't working even running after update release command

Loading

@davidworkman9
Copy link
Contributor

@davidworkman9 davidworkman9 commented Apr 3, 2014

This problem also exists with checkboxes (and I'm assuming radio buttons). After you check a checkbox and it's focused you no longer get notified of any changes that occur while focus is there, which is super annoying because what if the server rejects the check?

Loading

@glasser glasser added the Blaze label Apr 3, 2014
@dweldon
Copy link

@dweldon dweldon commented Apr 26, 2014

I think this is still broken. See this question on SO. Interestingly, it works if you remove focus from the element prior to changing the value.

Loading

@avital
Copy link
Contributor

@avital avital commented May 10, 2014

@davidworkman9 Server rejections are a good use-case -- thanks for pointing that out.

At first I was surprised about this report, since with Blaze we re-implement the same logic as we had on 0.7.2. So I ported @clubfest's report to 0.7.2 (moving Session.set('greeting', 'hi ') out of the rendered callback). Then the issue indeed doesn't happen.

But there's a different bug on 0.7.2 -- focus on the button is also lost after you click on it. This is because we re-render the entire hello template. So I added Template.hello.preserve(['input']), which brings the behavior closer to on Blaze which "preserves" all elements. Boom! The same issue on 0.7.2.

We should at least find a way to reproduce the behavior we had on 0.7.2. Not sure off the top of my head how to achieve it -- we'd need a way to force re-rendering a block. Maybe {{#rerender foo}} ... {{/rerender}} that re-renders when foo is invalidated? That would still make it cumbersome to write forms...

Loading

@jbonigomes
Copy link

@jbonigomes jbonigomes commented Nov 19, 2015

I am having this problem with Meteor version 1.2.1

Loading

@rista404
Copy link

@rista404 rista404 commented Dec 29, 2015

Same here.

METEOR@1.2.1

Loading

martijnwalraven pushed a commit that referenced this issue Feb 22, 2016
On Blaze, we copied functionality we had on Spark: Don't update
form controls (INPUT, TEXTAREA) if they are focused and their underlying
value reactively updates. This was never meant to be the eventual
solution -- we'd eventually have a way to define strategies for two-way
data binding. Maybe you'd be able to define a callback that notifies
the app when a change happens to a field that hasn't been saved yet.

Moreover, not only is the feature incomplete, but with Blaze it works
much more poorly than in Spark. Due to fine-grained updates, users
his this more frequently and don't seem to like the behavior
(in Spark you would only hit this behavior if you set up your
preserve rules exactly right, which many users did not do).

So, we're just ripping out this functionality. Now if a field gets
edited by some other user while you're focused it will just lose its
value. Focus will remain.

Fixes #1965
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants