-
Notifications
You must be signed in to change notification settings - Fork 26.5k
Review pass & fixup of the control directive & related code #63068
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review pass & fixup of the control directive & related code #63068
Conversation
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.
Calling out some TODOs in case we want to address any of them during this PR
35f39b4
to
b589dee
Compare
b589dee
to
a7717bd
Compare
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 don't really have answers for a lot of the questions/TODOs. Would it make sense adding them to the backlog and linking the TODOs to those issues–or did you mean to address them all before landing this?
8ac7f85
to
69a9b9f
Compare
re: TODOs - hoping Alex will have a chance to comment on some of them, if not I'll leave them in an add an item to our backlog |
Also notes a few properties in comments that we should consider supporting if possible
this allows cleaning up hacky test code to run it in node
Co-authored-by: Leon Senft <leonsenft@users.noreply.github.com>
69a9b9f
to
539e3b9
Compare
539e3b9
to
f4b717c
Compare
// TODO: `ValidationError` and `DisabledReason` are inherently tied to the signal forms system. | ||
// They don't make sense when using a ccontrol separately from the forms system and setting the | ||
// inputs individually. Givn that, should they still be part of this interface? |
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.
When in doubt, keep the API smaller? If they don't make sense maybe we leave it out unless there's a clear use case or requirement for them?
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'm pretty sure we will want them in some form, but we may want to make the types more friendly to standalone use. I'll address the TODO in a followup after Alex has a chance to chime in
9866f91
into
angular:prototype/signal-forms
No description provided.