-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
Components don't reset their received parameters during hot reload updates #31272
Comments
Thanks for contacting us. |
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process. |
@mkArtakMSFT @SteveSandersonMS Can we reconsider this one for .NET 6? This issue was hit in vendor exploratory testing. |
FWIW, I've been hitting this all the time when working with a UI framework that promotes using components in most places instead of plain HTML -- it's extremely common (and highly frustrating) to completely remove a It's especially egregious for boolean parameters, where the parameter is either specified or omitted, and yet trying to remove it after initially specifying it has no effect. Although doing an |
Thanks @uecasm for that feedback! This helps us prioritize as we evaluate this work for .NET 7. |
This is my least concern, there are dozens of other cases which break the app state after hot-reload. So I just click refresh, it takes less than a second. The problem is that hot-reload still takes 45 seconds on some .razor files. |
Done in #43418 |
It's a bit unusual to remove a parameter value that you're passing to a child component, but if you do, our upcoming hot-reload-refresh mechanism doesn't yet account for it.
Repro: In the default project template, in
Index.razor
, change this:... to this:
<SurveyPrompt />
No change will show up in the UI. This is because the existing
SurveyPrompt
instance already has a value for itsTitle
property. Failing to supply a new value just means that the old one doesn't get overwritten.Expected resolution
We can't control how all
IComponent
types deal with the removal of an incoming parameter value, but forComponentBase
at least, we can add some logic toSetParametersAsync
that checks theIsHotReload
flag and, if found, runs through some new code path todefault
-out all of its[Parameter]
properties before receiving the new set from its parent.Severity
Low. I don't think this is a common scenario at all.
The text was updated successfully, but these errors were encountered: