paper-input: Fix md-input-has-value when value attr is not observable

[dustinfarris]

Given the API for paper-input, we cannot assume that the user is going to update the original value object in their provided onchange closure. We also cannot assume that the provided value is observable.

This adds a new property to track the actual value of the input for things like binding the md-input-has-value class.

Fixes #411

[miguelcobain]

Given the API for paper-input, we cannot assume that the user is going to update the original value object in their provided onchange closure.

Where do we assume that?

We also cannot assume that the provided value is observable.

What do you mean? We're just using a computed property which depends on value. I don't see a case where that isn't "observable".

[dustinfarris]

@miguelcobain look at the last test I wrote for this PR. That test fails without the proposed change.

[dustinfarris]

@miguelcobain in that test the provided "value" is a static empty string (not observable). Also onChange does nothing. So while the value of the input changes, nothing else happens. But for purposes of applying the right classes such as md-input-has-value we need to track the actual change of the input without caring necessarily if the user could or did update the value in the onchange action.

[miguelcobain]

@dustinfarris paper-input should reflect whatever value it gets from outside. That's the DDAU philosophy.
So, I think a hasValue property should be true only if the outside world did update that value.

[dustinfarris]

@miguelcobain DDAU is still honored by making this a oneway, but we also have to honor MD style rules with the input element itself when its internal value deviates as could easily happen. Otherwise we have bugs like #411

[miguelcobain]

Let's imagine the following scenario:

• user types "aaa"
• with your PR, paper-input will overwrite _internalValue with "aaa", making it no longer a oneWay binding (Correct me if I'm wrong, please.)
• onChange is triggered 3 times
• for some reason, the user wants this specific input to be emptied when length is 3. The user does that in the action and updates value.
• since _internalValue is no longer bound to value you end up with different value and _internalValue

In this case I don't think this PR honors DDAU entirely because: the component should always reflect the state it is given (data down).

[dustinfarris]

Ok, I am unsure how computed oneway will react to an update like that after it deviated. I'll write a test for this when I'm back at my desk and adjust the implementation if necessary.

[miguelcobain]

Strange things happen when you don't update the input's value in normal ember/hbs.

Example: https://ember-twiddle.com/a0f4c6ce8ab25734634aadc74e76509d

In that twiddle the user wanted to always have 123 regardless of what the user types.
It only works on the first time. It is complicated. Previous discussions about this on ember's slack ended up with no solution.

[dustinfarris]

Ok agreed that this may not be the right approach. The end goal here is to make sure that we apply the md class if the input element has a value. I will rethink implementation to achieve that.

[miguelcobain]

Thank you for your time.

[dustinfarris]

@miguelcobain I've added an observer to ensure that future changes to value are reflected as you would expect with DDAU philosophy. Also renamed hasValue to inputHasValue to more accurately describe what is being referred to (_internalValue is now inputValue). There is an additional test to show this working.

I believe this is good to merge now.