Add readonly to FormControl formstate

[Fank]

I'm submitting a ... (check one with "x")

[ ] bug report => search github for a similar issue or PR before submitting
[x] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Currently there is a "disabled" flag which will disable the control, and also disable the validator.
But there also should be a "readonly" flag which do not disable the validator.

Current behavior

• Does not exist -

Expected behavior

• Explained above -

What is the motivation / use case for changing the behavior?

Please tell us about your environment:

• Angular version: 2.0.0-rc.6
• Browser: [all]
• Language: [all]
• Node (for AoT issues): node --version = 6.5.0

[pkozlowski-opensource]

Why it should differ in terms of validation as compared to disabled? In both cases a user can't interact with a control (can't change it value) so there is no user input to validate...

Could you elaborate on your exact use-case?

[Fank]

If i look from this side, you are right, both have exactly the same behaviour.
Thanks for clearing 👍

[dagstuan]

@pkozlowski-opensource A simple use case for a readonly control that needs validation would be a datepicker, where you dont want the user to enter a date via an <input type="text" />, but rather pop up a js-datepicker and populate the value of the input via the picker. If the input is disabled, browsers would not allow the user to interact with the input, but if it's readonly the user can still interact with it and it needs validation.

Currently it works well to just use bindings in the template for this functionality, but if the reasoning behind implementing enable() and disable() for form controls is to avoid using template bindings for this stuff, it makes sense to be able to set a control as readonly from the model as well.

[pkozlowski-opensource]

@dagstuan this use-case speaks to me!

[pkozlowski-opensource]

Well, actually partly only :-) If a control is a read-only then a icon to open a calendar should be disabled as well, right? Which means that a user still can't enter a date.

For me the only difference between disabled and readonly would be that the readonly field will be submitted while a disabled not. In both cases a user shouldn't be able to interact with the entire control....

I'm tempted to close it again :-)

[Fank]

Our usecase for date inputs is, an default input[type="text"] with a datepicker on it. So the user can enter a date as normal but also can use the datepicker.
We don't want to only provide a "datepicker" for our users because sometimes (its more the often one) they copy paste dates from something elsewhere and edit them manualy.
So if we only provide them a datepicker it would be a wrong behavior, because its a input where you can "inject" something with a other tool, but can enter something on your own.
So there is no usecase for a readonly.

[Fank]

If you want that the user only enter something valid, than use a validator. and highlight it with styles.

[dagstuan]

@pkozlowski-opensource a browser will allow focus on a readonly input, but not on a disabled one, so if an input is read only it will still get focus if the user tabs trough the form or clicks on it.

@Fank sure, you can solve a datepicker by having an input that isn't readonly. However, people are going to solve this in different ways, and given that <input readonly /> is valid html it makes sense for reactive forms to have the attribute if the point is to avoid using template bindings to control the inputs (given the whole "changed after checked" debacle).

[kara]

I actually think this is a valid feature request. We were considering doing this already when designing the disabled functionality, so this issue should stay open.