-
Notifications
You must be signed in to change notification settings - Fork 10.1k
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
Blazor input component support when EditContext is not supplied #35640
Blazor input component support when EditContext is not supplied #35640
Conversation
Something else to consider: Do we want validation styling to apply to input components without a parent Update: One case I forgot about is if the input's current value cannot be converted to the desired type, in which case the css class would be |
We've been playing somewhat loosey with nullable annotations as we work thru the repo. One could further argue that the current annotations are incorrect to begin with given if you create a new component, the edit context is null even though the compiler says otherwise: ie.. var inputText = new InputText();
Console.WriteLine(inputText.EditContext.ToString()); // The compiler will claim this is null safe, even though we know this will null-ref How does it look if we make |
Good to know - I'll give the other approach a go. |
@pranavkm I've updated the implementation to allow
...is no longer relevant because validation styling won't happen without an edit context. It's probably better this way, since validation styling would just get in the way if no actual validation was happening. |
@@ -848,6 +848,47 @@ public void InputRangeAttributeOrderDoesNotAffectValue() | |||
Browser.Equal("210", () => rangeWithValueLast.GetDomProperty("value")); | |||
} | |||
|
|||
[Fact] |
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've only added tests verifying that InputSelect
and InputRadioGroup
work without a parent EditForm
, since they contain most of the unique logic of the input components (other logic comes from InputBase
). InputRadioGroup
is a bit special in that it still calculates its own styling. The InputSelect
test verifies that complicated binding scenarios still work (binding to arrays, boolean values).
It also appears that the CI is a bit unhappy that the baseline API files are getting modified (by making |
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.
Looks great. @javiercn could you have a look since you said you did something similar?
…uck/input-components-without-edit-context
Blazor input component support when EditContext is not supplied
This PR enables Blazor input component functionality (
InputText
,InputSelect
, etc.) when noEditContext
is provided by a parentEditForm
.PR Description
The current approach solves the issue by allowing
InputBase.EditContext
to benull
. Validation styling won't be applied to input components without anEditContext
.Fixes #27804