Closed markcellus closed 7 years ago
Awesome! Thanks
Doing this accidentally made input two-way bound, I didn't want that behaviour.
The test I had to prevent this had a mistake (see the call to trigger
) which meant I didn't catch it.
I'm going to have to make the input component not extend Ember's TextField, but I will keep the same attribute bindings.
I see. Yeah I never understood exactly why Ember's input helper is two-way bound by default. Seems like it makes more sense to pass it actions to respond to value changes.
Just curious though, can't you just use Ember.computed.oneWay
to force one-way binding?
Don't think so, one way cp can't bind value
to itself?
have a play if you like :)
Yup, definitely. I believe it's commonly understood that the input helper's value
property is two-way binded by default. So to force it to use one-way binding, I think people know to do {{input value=(readonly myValue)}}
based on the documentation.
In your twiddle example, if one-way is desired, instead of doing:
{{my-input1 value=myObj.value1}}
you would do
{{my-input1 value=(readonly myObj.value1)}}
I hear Ember is going to eventually change this in future versions so that the {{input}}
helper's value
is not two-way bound by default and you will explicitly have to declare it to be using the {{mut}}
helper.
Ah yes of course, how would you like to proceed? ;)
Oh, I was just informing you. Using a custom <input>
component element is fine--all attributes you've bounded cover my use-case. But you'll just have to keep adding attributeBindings
as new input attributes are added to the HTML spec (and any custom ones that may be added by Ember in the future). But if you're fine with doing that, it's cool with me too. ;)
yeh, fine with that. ty
Would it be acceptable to have select-box/input.js extend Ember's TextField class to have it behave like the
{{input}}
helper and pass all properties that the{{input}}
helper allows?