zestia / ember-select-box

:capital_abcd: A faux select box for Ember apps
MIT License
64 stars 14 forks source link

Input component should extend Ember's TextField #13

Closed markcellus closed 7 years ago

markcellus commented 7 years ago

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?

amk221 commented 7 years ago

Thanks https://github.com/amk221/ember-select-box/commit/a5d62137cbc928d37bb4bdd2cd820bcea0483f49

markcellus commented 7 years ago

Awesome! Thanks

amk221 commented 7 years ago

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.

markcellus commented 7 years ago

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.

markcellus commented 7 years ago

Just curious though, can't you just use Ember.computed.oneWay to force one-way binding?

amk221 commented 7 years ago

Don't think so, one way cp can't bind value to itself? have a play if you like :)

markcellus commented 7 years ago

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.

amk221 commented 7 years ago

Ah yes of course, how would you like to proceed? ;)

markcellus commented 7 years ago

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. ;)

amk221 commented 7 years ago

yeh, fine with that. ty