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

_isSetting flag race condition when we're trying to change an input class based on input value #230

Open
fcamblor opened this issue Oct 28, 2016 · 0 comments

Comments

@fcamblor
Copy link
Contributor

Hi,

I just hit an issue while defining multiple binder on the same field.

Typically, if I have following input field :

<div id="content">
  <input type="text" name="foo" />
</div>

and I define following model binder :

    this._modelBinder.bind(model, this.el, {
      'foo': [{
        selector: '[name=foo]'
      }, {
        selector: '[name=foo]',
        elAttribute: 'class',
        converter: function(model, value) {
          console.log("class elAttribute triggered for foo");
          return (value && value.length>3)?"error":undefined;
        }
      }]
  });

The "class elAttribute triggered for foo" log is only displayed during model binder initialization, but never after (typically, when my foo attribute is modified)

This is due to the _isSetting lock put on target el (which is the same between both elementBinding in our case) :

  • When copyViewValuesToModel() is called, we enter the _copyViewToModel() on first elementBinding
  • The _isSetting lock is put on the target el (which is the same for the other elementBindings)
  • _setModel() and _copyModelToView() is called, iterating over every elementBindings.
  • The first one is ignored because of the _isSetting lock, but the second one (which is targetting the same element) is ignored as well, preventing class attribute to be calculated/updated.

I don't see how we could elegantly workaround this issue.

Anyway, if I use a DOM wrapper around my input for handling this class change, it works perfectly.

See following jsfiddle which demonstrates the issue and the workaround :

  • If you enter an input value longer than 3 chars on 1st input, no error class is defined on the input, where if you do on the second input (which is wrapped into a .field-container element), it works fine.

Regards,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant