-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Provide a tooling gesture that suggests values for required component parameters are not specified. #33384
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
Conversation
… parameters are not specified.
src/Razor/Microsoft.AspNetCore.Razor.Language/src/BoundAttributeDescriptor.cs
Outdated
Show resolved
Hide resolved
@@ -28,6 +28,8 @@ public abstract class BoundAttributeDescriptorBuilder | |||
|
|||
public abstract RazorDiagnosticCollection Diagnostics { get; } | |||
|
|||
internal bool IsEditorRequired { get; set; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Conflicted with this concept being on the BoundAttributeDescriptor
vs. the RequiredAttributeDescriptor
. I know the RequiredAttributeDescriptor
has a slightly different implementation detail (aka effects if the TagHelper binds) but I still wonder if we're maybe crossing concerns. Did you happen to think more about the two options?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@SteveSandersonMS brought this up yesterday.
Right now, a tag helper attribute that is required but is missing causes the binding to fail. As a result, you lose colorization, don't get completion / documentation / tooltips, and you get the warning that says this tag looks like a component but did not bind.
If there's a way to improve this experience (keep colorization and completion and provide a better warning), we could use the current implementation.
return component; | ||
} | ||
|
||
private MarkupElementIntermediateNode RewriteAsElement(TagHelperIntermediateNode node) | ||
private static void ValidateRequiredAttributes(TagHelperIntermediateNode node, TagHelperDescriptor tagHelper, ComponentIntermediateNode intermediateNode) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, I'm not sure that this (the IR pass) is the right location to log diagnostics for this. Would it be possibel to log these diagnostics on the TagHelperElement syntax nodes? It'd enable us to have a better association with what element was the "problem" element and would enable tooling to react appropriately (aka generate the required attributes)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any pointers on where that would be? This seemed like the earliest place where things like child components were resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty solid change!
The only high level question I have is whether or not you have a way to turn off the warnings per component or whether we need to.
I'm thinking about how this works with component hierarchies where more specialized components might relax the requirements (for example provide a default value for a required parameter).
So an iffy workaround right now is to pass a splat attribute if you wanted to suppress it per callsite. Using a |
I'm fine as long as we have a way, no matter how ugly it is. Another way to go about this would be to have a directive to explicitly disable the checks. |
Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:
|
|
||
var diagnostics = Assert.Single(generated.Diagnostics); | ||
Assert.Equal(RazorDiagnosticSeverity.Warning, diagnostics.Severity); | ||
Assert.Equal("RZ2012", diagnostics.Id); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit weird. It looks like there is child content:
<ComponentWithEditorRequiredChildContent>
</ComponentWithEditorRequiredChildContent>
Syntactically it looks like the child content is a "newline" character. What makes this illegal? Maybe you actually want a single newline character as child content. Does the Razor compiler special-case this into "no child content parameter"?
Overall since [EditorRequired]
isn't default, I wouldn't expect most developers to put it on a ChildContent
parameter. I suppose if they do put it on, then they are really determined to get some child content so perhaps "whitespace" should count as violating their rule.
Summary: it's not obvious what the right behavior should be, but I guess I'm fine with [EditorRequired]
erring on the side of strictness since if the developer wants not to be strict, they just wouldn't use it in the first place.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this particular case, the child contents are named (it's Found
and NotFound
like the Router
component), so this particular error makes sense. However, I wasn't sure what the behavior looked like when specifying text as a child content:
For a component with a parameter like so, here's the behavior:
[EditorRequired][Parameter] public RenderFragment ChildContent { get; set; }
- ✔️ Having non-whitespace text does not produce a warning eg.
<MyComponent>Hello world</MyComponent>
- ✔️ Having any markup or component tag does not produce a warning e.g.
<MyComponent><Counter /></MyComponent>
- ❌ One or more whitespace is treated as missing ChildContent which produces a warning:
<MyComponent></MyComponent>
- ✔️ You can specify an explicit tag if you do want whitespace to be treated as valid content
<MyComponent><ChildContent> </ChildContent></MyComponent>
I feel bullet no 3 should help guide the most common use case of the editor completing the tag for the user while 4 covers the case if you need to workaround any undue compiler restrictions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great. Really nice!
@NTaylorMullen my plan is to get this in for p6. We should be able to refactor this at a later time since none of the implementation details are public / breaking to anything outside the tooling. |
@pranavkm @SteveSandersonMS |
Hi @En3Tho. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context. |
… parameters are not specified. (dotnet/aspnetcore#33384) * Provide a tooling gesture that suggests values for required component parameters are not specified. Fixes dotnet/aspnetcore#11815 Commit migrated from dotnet/aspnetcore@e02723975a97
Something worth noting. Adding |
Hi @fardarter. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context. |
Fixes #11815