Skip to content

Update visibility of component parameters #8825

Closed
@rynowak

Description

@rynowak

Summary

We have to make a final decision about the visibility of component parameters. We've run into many issues trying to use non-public properties, and I don't think these are going to stop.

Problems and Goals

  • We want to make it hard or impossible to set a component parameter property directly. This is never correct when done in application code
  • We've tried using non-public properties and found a bunch of things that don't work
    • Reference docs require public
    • Reference assemblies require public
    • Our metadata analysis has (possibly fragile) workarounds in place that we use to look at non-public properties
  • We want whatever we choose to work with AOT, but we don't exactly know the requirements. It's generally assumed in AOT that unused non-public code is dead code and can be removed.
  • We want whatever we choose to work with testing, but we don't know the requirements of that yet

TLDR we have given non-public properties a try and the results aren't great. We got here because we now have to maintain ref assembly code for our components manually. It would be great if the guidance for users worked for us as well.

Some options

We could recommend that users use public get properties, and we will call the setter regardless of its visibility.

We could recommend that users use public get/set properties and we will write an analyzer to tell you not to set component parameter properties.

I don't like the option that we'd keep on doing analysis over non-public properties. We don't do this anywhere else I can think of, and I don't have confidence that this will play out in our favor wrt tooling.

Conclusion

We have a conclusion here!

Preview 8

  • Reference the component analyzer package from .Components
  • Add analyzer to warn if a parameter is set in code outside of the inheritance hierarchy or a nested class
  • Update our samples
  • Verify [CascadingParameter]s do not get Analyzesr warnings impacted
  • Don't pass analyzers to the declaration compilation target
  • Add our component analyzer package to the SDK
  • Add a .targets file to our analyzer package to avoid duplicates when included by both the SDK and package
  • Make parameters public get/set
  • Add analyzer to warn if a property is not public get/set and has [Parameter]
  • Update our tests

Before final release

We can leave [CascadingParameter] properties alone. They don't interact with tooling, don't want documentation, and don't represent a public contract.

Metadata

Metadata

Assignees

Labels

DoneThis issue has been fixedarea-blazorIncludes: Blazor, Razor Components

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions