Please reopen #26016

[mrpmorris]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I feel this was closed prematurely, can it be reopened please @danroth27 @SteveSandersonMS @captainsafia
#26016

Describe the solution you'd like

That ticket reopened :)

Additional context

No response

[javiercn]

@mrpmorris thanks for contacting us.

We appreciate your suggestion and the thought you’ve put into this matter. While we understand the appeal of a global hook for deep change detection, we’ve decided not to implement this feature for several reasons, that we mentioned on the original issue.

First, even though record types in C# look like they’re immutable, they can actually contain mutable properties. To reliably determine if something is deeply immutable, we would have to inspect every field and property, even private ones. This approach could introduce subtle and confusing bugs—for example, if someone adds a mutable field to a type, it could unexpectedly change how rendering works in an application. We want to avoid creating these kinds of traps for developers.

Also, in many cases, simply comparing two values for equality doesn’t answer the real question: has the object actually changed? The core issue is whether an object has mutated, not just if two references are equal. For those who need detailed control, Blazor already lets us override the SetParametersAsync and ShouldRender method in component base.

One such option is to create your own base class:

public abstract class ChangeAwareComponent : ComponentBase
{
    private bool _anyParameterChanged;

    public override Task SetParametersAsync(ParameterView parameters)
    {
        _anyParameterChanged = false;
        parameters.SetParameterProperties(this);
        return !_anyParameterChanged : Task.CompletedTask ? base.SetParametersAsync(parameters);
    }

    protected void MarkAsChanged() => _anyParameterChanged = true;
}

Then for any property you care about checking:

public class MyWidget : ChangeAwareComponent
{
    private MyModel _data;

    [Parameter]
    public MyModel Data
    {
        get => _data;
        set
        {
            if (!EqualityComparer<MyModel>.Default.Equals(_data, value))
            {
                _data = value;
                MarkAsChanged();
            }
        }
    }
}

We believe only the app developer can truly know whether their state is unchanged. However, providing a global mechanism for this in the framework would add significant complexity and potential for error and break encapsulation for third-party components, which is something we strongly want to avoid.

We understand that we might not agree here on the philosophy, but I hope at least you can understand our reasoning behind it.

[mrpmorris]

Hi @javiercn - I am not under the impression that records are immutable. I just mention that I use records for my immutable state.

The idea of using IEquatable is mentioned in the ticket and rejected.

Additionally, this request is not about how I can override ShouldRender in my own components + pages, but how Blazor can be more optimal in general. This would include 3rd party libraries that we have no control over the source of.

Take a grid as an example. If the parent page renders then the grid will render, and so will each and every component that represents a row in the grid. With a way to identify objects as immutable, we would instead see the page render and also the grid, but not a single row would need to.

An alternative suggestion for implementation mentioned by @SteveSandersonMS was

What we have considered is an attribute like [TreatAsDeeplyImmutable] you could put on any type if you wanted the system to behave as if it was deeply immutable (whether or not it actually is).

This would actually be an excellent solution, but only if the attribute were available in the main .Net libraries (DataAnnotations) and not Blazor - otherwise non-Blazor projects that contain contracts for an API would need a dependency on Blazor (which is not logical).

It is also fully backwards compatible, because people would have to explicitly state that they want this new behaviour (e.g. by decorating their classes with the attribute). If doing so affects 3rd party libraries then the developers would raise a feature request for them to take it into account - and in the meantime not use it.

In fact, it could even be added behind a feature toggle so it can be disabled in the rare cases where the developer doesn't have control over the source code for either the components or the data models.

And it's a very simple change in ChangeDetection

if (ReferenceEquals(oldValue, newValue) && IsMarkedAsImmutableType(newValue.GetType())
  return false;

I can see no reason not to implement the attribute approach.

Should I perhaps raise that as a new ticket to avoid confusion about the request? The problem is, it would need an addition to the DataAnnotations assembly - and they are unlikely to make such a modification unless there is an appetite for it in Blazor.

Here is a small selection of public posts of people commenting on over-rendering in Blazor. There are more, but this should suffice.

1. https://www.reddit.com/r/Blazor/comments/sx8raj/prevent_bindvalue_rerendering_entire_page
2. https://www.reddit.com/r/Blazor/comments/ugi9qd/why_is_blazors_rendering_so_inefficient/
3. Blazor Performance Diagnostics for Re-Rendering and Execution times. #38984
4. Blazor change detection too liberal #13610
5. Use IEquatable for Blazor object parameters to optimize rendering by default #40867
6. Extend API for component attributes with render-comparer different from its value #21915

[StevenTCramer]

Blazor’s re-rendering issues aren’t theoretical—I’ve had to craft custom base components to bypass performance bottlenecks, and #26016 highlights similar struggles. I think the Blazor team could address the needs of the community in a short, focused session and make Blazor even better. Honouring an immutable identifier would be a good step, and that having a feature flag to disable it sounds like a good idea

[mrpmorris]

I'll close this and create a new ticket, to avoid confusion

[mrpmorris]

@javiercn @StevenTCramer I have created a new ticket here #62570