[release/8.0] [Blazor] Fix @key not being respected for interactive WebAssembly components after publish
#53748
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fix
@keynot being respected for interactive WebAssembly components after publishBackport of #53746
Fixes an issue where, after publishing a Blazor Web App, components with the
InteractiveWebAssemblyrender mode could not receive parameter updates from SSR updates. If the component received any changed parameters, it would always get destroyed and re-initialized regardless of whether a matching@keywas present.Description
The problem was that members of
ComponentMarkerKeywere getting trimmed away after publish. The fix adds new trimming attributes to preserve the members ofComponentMarkerKey.Fixes #53289
Customer Impact
Without this fix, customers will not be able to preserve component instances between enhanced page updates if any component parameters change. This includes enhanced navigations (navigating from one internal page to another), and enhanced form posts. Because this is a problem specific to publishing, customers may not realize this bug exists in their app until it's deployed.
Regression?
This bug is specific to apps utilizing static server rendering, which is a new feature in .NET 8.
Risk
The fix is trivial and very unlikely to negatively impact other functionality.
Verification
Packaging changes reviewed?