UUF: BL0007 doc: add SetParametersAsync example for parameter identification

### Description

# User feedback transferred from UUF System:

> "OnParamerterSet" and "OnParameterSetAsync" are not a viable solution to eliminate BL0007. In the section "How to Fix Violations" they should put a link to "SetParametersAsync" with an example of how to know exactly what parameter was modified."

**Enhance BL0007 documentation with SetParametersAsync example for parameter identification**

**Problem Statement:**
The current documentation for rule BL0007 ("Component parameter should be auto property") only recommends using `OnParametersSet` or `OnParametersSetAsync` as solutions for fixing violations. As noted in the user feedback above, these methods don't provide a way to determine exactly which parameter was modified. This limitation is significant for developers who need to know which specific parameter changed to implement appropriate handling logic.

**_[AI assisted, review proposal carefully]_**
**Proposed Solution:**
Enhance the "How to fix violations" section in the BL0007 documentation to include information about overriding `SetParametersAsync` as an additional solution, with a code example demonstrating how to identify which specific parameter was modified.

**Specific Changes Needed:**
In file: `aspnetcore/diagnostics/bl0007.md`

Current text (from "How to fix violations" section):
```markdown
## How to fix violations

Implement the component parameter as an auto property and override or in the component class to read or transform the parameter's value. For more information, see the [OnParametersSet{Async} lifecycle method](xref:blazor/components/lifecycle#after-parameters-are-set-onparameterssetasync).
```

Proposed enhancement:
```markdown
## How to fix violations

Implement the component parameter as an auto property and override or in the component class to read or transform the parameter's value. For more information, see the [OnParametersSet{Async} lifecycle method](xref:blazor/components/lifecycle#after-parameters-are-set-onparameterssetasync).

Alternatively, when you need to know exactly which parameter was modified, override . This approach provides direct access to the `ParameterView` and allows for identifying specific parameter changes:

```csharp
public class MyComponent : ComponentBase
{
private string _previousMessage;

[Parameter]
public string Message { get; set; }

[Parameter]
public int Count { get; set; }

public override Task SetParametersAsync(ParameterView parameters)
{
// Capture previous value before base implementation updates it
_previousMessage = Message;

// Allow the framework to set parameter values
var task = base.SetParametersAsync(parameters);

// Check if specific parameters were in the incoming set
if (parameters.TryGetValue(nameof(Message), out var newMessage)
&& newMessage != _previousMessage)
{
// The Message parameter has changed
Console.WriteLine($"Message changed from '{_previousMessage}' to '{newMessage}'");

// Custom handling for Message parameter changes
HandleMessageChange(newMessage, _previousMessage);
}

return task;
}

private void HandleMessageChange(string newValue, string oldValue)
{
// Implement custom handling logic
}
}
```

For more information about component initialization and the `SetParametersAsync` method, see [Component initialization (`SetParametersAsync`)](xref:blazor/components/lifecycle#component-initialization-setparametersasync).
```

**Rationale:**
This enhancement provides a more comprehensive solution for developers who need finer control over parameter handling. While `OnParametersSet` and `OnParametersSetAsync` are appropriate in many cases, they don't offer a way to determine which specific parameter triggered the update. The `SetParametersAsync` approach addresses this limitation by providing access to the incoming parameter values before they're applied, enabling developers to:

1. Identify exactly which parameter changed
2. Compare new values with previous values
3. Implement parameter-specific handling logic
4. Maintain control over the parameter setting process

**Additional Context:**
This enhancement is based on user feedback suggesting that the current documentation doesn't provide adequate guidance for cases where developers need to know which specific parameter was modified. By including this additional solution with a concrete code example, we're giving developers better tools to properly handle component parameters while still adhering to the intent of the BL0007 rule.

**Related Documentation:**
- [Component lifecycle](xref:blazor/components/lifecycle)
- [Component parameters](xref:blazor/components/index#component-parameters)

### Page URL

https://learn.microsoft.com/en-us/aspnet/core/diagnostics/bl0007?view=aspnetcore-9.0

### Content source URL

https://github.com/dotnet/AspNetCore.Docs/blob/main/aspnetcore/diagnostics/bl0007.md

### Document ID

08e513b6-eaa9-9586-289f-3fe1c5dc1761

### Platform Id

1c6a179e-0f07-a2e5-5fe2-bc87b7cd6b67

### Article author

@guardrex

### Metadata

* ID: 08e513b6-eaa9-9586-289f-3fe1c5dc1761
* PlatformId: 1c6a179e-0f07-a2e5-5fe2-bc87b7cd6b67
* Service: **aspnet-core**

[Related Issues](https://github.com/dotnet/AspNetCore.Docs/issues?q=is%3Aissue+is%3Aopen+08e513b6-eaa9-9586-289f-3fe1c5dc1761)