Skip to content
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

Closed
SteveSandersonMS opened this issue Mar 26, 2021 · 7 comments · Fixed by #43418
Closed

Components don't reset their received parameters during hot reload updates #31272

SteveSandersonMS opened this issue Mar 26, 2021 · 7 comments · Fixed by #43418
Assignees
Labels
area-blazor Includes: Blazor, Razor Components bug This issue describes a behavior which is not expected - a bug. feature-hot-reload This issue is related to the Hot Reload feaature Priority:1 Work that is critical for the release, but we could probably ship without
Milestone

Comments

@SteveSandersonMS
Copy link
Member

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:

<SurveyPrompt Title="How is Blazor working for you?" />

... to this:

<SurveyPrompt />

No change will show up in the UI. This is because the existing SurveyPrompt instance already has a value for its Title 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 for ComponentBase at least, we can add some logic to SetParametersAsync that checks the IsHotReload flag and, if found, runs through some new code path to default-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.

@SteveSandersonMS SteveSandersonMS added the area-blazor Includes: Blazor, Razor Components label Mar 26, 2021
@mkArtakMSFT mkArtakMSFT added the bug This issue describes a behavior which is not expected - a bug. label Mar 29, 2021
@mkArtakMSFT mkArtakMSFT added this to the Next sprint planning milestone Mar 29, 2021
@ghost
Copy link

ghost commented Mar 29, 2021

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. Because it's not immediately obvious that this is a bug in our framework, we would like to keep this around to collect more feedback, which can later help us determine the impact of it. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

@ghost
Copy link

ghost commented Aug 3, 2021

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.

@danroth27
Copy link
Member

danroth27 commented Oct 1, 2021

@mkArtakMSFT @SteveSandersonMS Can we reconsider this one for .NET 6? This issue was hit in vendor exploratory testing.

@mkArtakMSFT mkArtakMSFT modified the milestones: Backlog, .NET 7 Planning Oct 11, 2021
@mkArtakMSFT mkArtakMSFT added Priority:1 Work that is critical for the release, but we could probably ship without triaged labels Nov 11, 2021
@MackinnonBuck MackinnonBuck self-assigned this Apr 18, 2022
@uecasm
Copy link

uecasm commented Apr 27, 2022

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 Class or other parameter and then be surprised when nothing changes in the rendered content until a full reload.

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 = default on hot reload is not really a solution, as some parameters will have a different default in their construction code. It may be sufficient to require that such parameters use DefaultValueAttribute, however. Alternatively, if hot reload detects that at least one of a component's parameters have been removed, then it will need to re-create the component instead of just trying to update its parameters. This may be the safest option.

@danroth27
Copy link
Member

Thanks @uecasm for that feedback! This helps us prioritize as we evaluate this work for .NET 7.

@CommonLoon102
Copy link

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.
dotnet/razor#7626

@MackinnonBuck
Copy link
Member

Done in #43418

@ghost ghost locked as resolved and limited conversation to collaborators Oct 7, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-blazor Includes: Blazor, Razor Components bug This issue describes a behavior which is not expected - a bug. feature-hot-reload This issue is related to the Hot Reload feaature Priority:1 Work that is critical for the release, but we could probably ship without
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants