-
Notifications
You must be signed in to change notification settings - Fork 27.4k
fix(ngValue): setting binding to undefined should update the DOM value to an empty string #15605
Changes from 4 commits
6e30312
3ae9f0f
db99f4e
a8e2cec
a29ece6
496a2af
ffb122b
011c3a8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4211,6 +4211,22 @@ describe('input', function() { | |
expect(inputElm[0].getAttribute('value')).toBe('something'); | ||
}); | ||
|
||
it('should update the dom "value" to "" and attribute to null when the binding is set to undefined', function() { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would say something like:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The reason why I took this was because this test has a comparable way of describing itself: So combining my solution with yours, I'd propose:
Yet I do think this being somehow odd, talking about clearing both feels like having the same result for both. However, dom value is set to There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
👍
"Clear" is generic and can mean different things for different...things (e.g. property vs attribute). What we clear is an implementation detail - it doesn't have to go to the test description imo. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed. |
||
var inputElm = helper.compileInput('<input type="text" ng-value="value">'); | ||
|
||
$rootScope.$apply('value = \'something\''); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: Feel free to use |
||
|
||
expect(inputElm[0].value).toBe('something'); | ||
expect(inputElm[0].getAttribute('value')).toBe('something'); | ||
|
||
$rootScope.$apply(function() { | ||
delete $rootScope.value; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: This could be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not going to fix this nit as I prefer |
||
}); | ||
|
||
expect(inputElm[0].value).toBe(''); | ||
expect(inputElm[0].getAttribute('value')).toBe(null); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It turns out that in IE you can't remove the You can skip this expectation in IE, by checking the // Support: IE 9-11
// In IE it is not possible to remove the `value` attribute from an input element.
if (!msie) {
expect(inputElm[0].getAttribute('value')).toBeNull();
} There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should I do it this way, or just get rid of the except as this has nothing to do with my change ? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I prefer to keep the expectation on other browsers (even if it is not directly related to this PR, it is still relevant for the added test). |
||
}); | ||
|
||
they('should update the $prop "value" property and attribute after the bound expression changes', { | ||
input: '<input type="text" ng-value="value">', | ||
textarea: '<textarea ng-value="value"></textarea>' | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another idea (to avoid the arbitrary conversion to
null
) is to change toelement[0].value = value
. (I am not sure what is better.) It will not matter in most cases (e.g. when used with native inputs), only if someone is using it with a custom input.It turns out that in IE9
input.value = null
results ininput.value === 'null'
(same forundefined
). So we have a problem there.It matters in cases where
value
in alwaysundefined
(soupdateElementValue
will only run once at the beginning). Previously,element.prop('value', undefined)
would be ignored (and the initialvalue
will be kept), but now it will be set to'null'
(or'undefined'
).We could check for IE9 and set the value to
''
instead (and also add a "known issue" in the docs):(It is not ideal, but it is a good middleground imo - plus it will only affect IE9 users.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will update the PR with the
msie
check and usingisDefined
instead ofisUndefined
.If I get this straight, using
element[0].value = propValue
should be possible aswell? The difference is we're not using jQuery/jqLite in this case, which may be a better idea but I have no idea what you guys prefer...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am 99% sure it won't make a difference in this particular case, but let's stick to
.prop()
(because...it doesn't make a difference).BTW, I forgot to mention, you don't need the
angular.
prefix; justis[Un]Defined(...)
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed!
So for the docs part:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Leaving out
angular.
resulted in a broken build. But it looks like it's not related to that ?