-
Notifications
You must be signed in to change notification settings - Fork 10k
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
Implement *directive attribute* feature for components #6364
Comments
Does this mean being able to do things like *ngIf="" which only render components based on some condition? |
Indeed, we saw the problem on the validation feature : if you want to add an attribute you have to subclass the one offered by the framework. But I think we should keep it to feature like this (adding behavior to an html tag) and don't apply it to feature already present in razor (if/for ...) which is a not very beautiful in angular IMHO. |
The good thing about it is the ability to reduce nesting and in some ways make it more elegant to read. But I'm sure the right design will come for blazor with time so i have no worries for that. |
Thats exactly what I need in Blazor! |
- Expanded the directive attribute completion source (the piece that hooks into VS windows) to understand the parameter portion of a directive attribute. When we think we're operating on a directive attribute parameter we now restrict the applicable completion span to just be the parameter portion. - Added a directive attribute parameter completion provider. This provider only operates on directive attribute parametesr and tries to be smart about the parameter completions it offers. - Expanded the commit manager to now also handle `:` commits so users can seamless go from completing a directive attribute into completing a parameter. - Added new tests for the new parameter completion provider, completion source and commit manager. dotnet/aspnetcore#6364
- Updated the `RazorCompletionItem` type to no longer contain a `Documentation`/`Description` property because in completion scenarios descriptions are never readily available and don't make a lot of sense being on the completion item itself. This is also how Roslyn does completions. - We now utilize an item bag on `RazorCompletionItem`s to hold description data. Currently there's just two type of completion descriptions (directive and attribute). Based off of the completion item kind (directive or attribute) we can extract the appropriate description. The goal of this new description type was to represent all data for a completion in an unstructured way so each platform can display it using its own capabilities. - Added a description factory to convert description items into classified containers. Tried to replicate WTE's description look as much as possible. - Left out documentation parsing. Will do this at a later date; however directive attributes rarely have documentation specific pieces that require parsing so we handle the 90% case. - Updated existing tests to reflect the new documentation mechanisms for RazorCompletionItems. - Added new tests to validate the completion source and the description factory. dotnet/aspnetcore#6364
- Updated the `RazorCompletionItem` type to no longer contain a `Documentation`/`Description` property because in completion scenarios descriptions are never readily available and don't make a lot of sense being on the completion item itself. This is also how Roslyn does completions. - We now utilize an item bag on `RazorCompletionItem`s to hold description data. Currently there's just two type of completion descriptions (directive and attribute). Based off of the completion item kind (directive or attribute) we can extract the appropriate description. The goal of this new description type was to represent all data for a completion in an unstructured way so each platform can display it using its own capabilities. - Added a description factory to convert description items into classified containers. Tried to replicate WTE's description look as much as possible. - Left out documentation parsing. Will do this at a later date; however directive attributes rarely have documentation specific pieces that require parsing so we handle the 90% case. - Updated existing tests to reflect the new documentation mechanisms for RazorCompletionItems. - Added new tests to validate the completion source and the description factory. dotnet/aspnetcore#6364
- Expanded the directive attribute completion source (the piece that hooks into VS windows) to understand the parameter portion of a directive attribute. When we think we're operating on a directive attribute parameter we now restrict the applicable completion span to just be the parameter portion. - Added a directive attribute parameter completion provider. This provider only operates on directive attribute parametesr and tries to be smart about the parameter completions it offers. - Expanded the commit manager to now also handle `:` commits so users can seamless go from completing a directive attribute into completing a parameter. - Added new tests for the new parameter completion provider, completion source and commit manager. dotnet/aspnetcore#6364
- Updated the `RazorCompletionItem` type to no longer contain a `Documentation`/`Description` property because in completion scenarios descriptions are never readily available and don't make a lot of sense being on the completion item itself. This is also how Roslyn does completions. - We now utilize an item bag on `RazorCompletionItem`s to hold description data. Currently there's just two type of completion descriptions (directive and attribute). Based off of the completion item kind (directive or attribute) we can extract the appropriate description. The goal of this new description type was to represent all data for a completion in an unstructured way so each platform can display it using its own capabilities. - Added a description factory to convert description items into classified containers. Tried to replicate WTE's description look as much as possible. - Left out documentation parsing. Will do this at a later date; however directive attributes rarely have documentation specific pieces that require parsing so we handle the 90% case. - Updated existing tests to reflect the new documentation mechanisms for RazorCompletionItems. - Added new tests to validate the completion source and the description factory. dotnet/aspnetcore#6364
- Added a completion source to hook into VisualStudio's modern completion. To properly hook into VisualStudio I needed to restrict our completion events to only fire in potential attribute scenarios. When detecting potential directive attributes we needed to determine which parts of the completion would be replaced on a committed completion without having a SyntaxTree. To do this I do a fuzzy textual character search to find things that look like a directive attribute name or a parameter (`:parameterName`) following a directive attribute name. - Part of hooking into VS' completion engine involved handling the situation when legacy completion is active while modern completion is being invoked, to not have two completion lists pop up we dismiss the legacy completion sessions when we think we can provide completions. - Utilized the same image monikers as TagHelper element/attribute completions to make things seem seamless when alternating between legacy and modern completion. - Expanded the completion facts service to understand directive attribute names (not parameters). Had to handle malformed attributes, partially valid directive attributes, untyped attributes etc. - Added new tests to verify VS completion and completion facts service functionality. dotnet/aspnetcore#6364
- Expanded the directive attribute completion source (the piece that hooks into VS windows) to understand the parameter portion of a directive attribute. When we think we're operating on a directive attribute parameter we now restrict the applicable completion span to just be the parameter portion. - Added a directive attribute parameter completion provider. This provider only operates on directive attribute parametesr and tries to be smart about the parameter completions it offers. - Expanded the commit manager to now also handle `:` commits so users can seamless go from completing a directive attribute into completing a parameter. - Added new tests for the new parameter completion provider, completion source and commit manager. dotnet/aspnetcore#6364
- Updated the `RazorCompletionItem` type to no longer contain a `Documentation`/`Description` property because in completion scenarios descriptions are never readily available and don't make a lot of sense being on the completion item itself. This is also how Roslyn does completions. - We now utilize an item bag on `RazorCompletionItem`s to hold description data. Currently there's just two type of completion descriptions (directive and attribute). Based off of the completion item kind (directive or attribute) we can extract the appropriate description. The goal of this new description type was to represent all data for a completion in an unstructured way so each platform can display it using its own capabilities. - Added a description factory to convert description items into classified containers. Tried to replicate WTE's description look as much as possible. - Left out documentation parsing. Will do this at a later date; however directive attributes rarely have documentation specific pieces that require parsing so we handle the 90% case. - Updated existing tests to reflect the new documentation mechanisms for RazorCompletionItems. - Added new tests to validate the completion source and the description factory. dotnet/aspnetcore#6364
- Added a completion source to hook into VisualStudio's modern completion. To properly hook into VisualStudio I needed to restrict our completion events to only fire in potential attribute scenarios. When detecting potential directive attributes we needed to determine which parts of the completion would be replaced on a committed completion without having a SyntaxTree. To do this I do a fuzzy textual character search to find things that look like a directive attribute name or a parameter (`:parameterName`) following a directive attribute name. - Part of hooking into VS' completion engine involved handling the situation when legacy completion is active while modern completion is being invoked, to not have two completion lists pop up we dismiss the legacy completion sessions when we think we can provide completions. - Utilized the same image monikers as TagHelper element/attribute completions to make things seem seamless when alternating between legacy and modern completion. - Expanded the completion facts service to understand directive attribute names (not parameters). Had to handle malformed attributes, partially valid directive attributes, untyped attributes etc. - Added new tests to verify VS completion and completion facts service functionality. dotnet/aspnetcore#6364
- Expanded the directive attribute completion source (the piece that hooks into VS windows) to understand the parameter portion of a directive attribute. When we think we're operating on a directive attribute parameter we now restrict the applicable completion span to just be the parameter portion. - Added a directive attribute parameter completion provider. This provider only operates on directive attribute parametesr and tries to be smart about the parameter completions it offers. - Expanded the commit manager to now also handle `:` commits so users can seamless go from completing a directive attribute into completing a parameter. - Added new tests for the new parameter completion provider, completion source and commit manager. dotnet/aspnetcore#6364
- Updated the `RazorCompletionItem` type to no longer contain a `Documentation`/`Description` property because in completion scenarios descriptions are never readily available and don't make a lot of sense being on the completion item itself. This is also how Roslyn does completions. - We now utilize an item bag on `RazorCompletionItem`s to hold description data. Currently there's just two type of completion descriptions (directive and attribute). Based off of the completion item kind (directive or attribute) we can extract the appropriate description. The goal of this new description type was to represent all data for a completion in an unstructured way so each platform can display it using its own capabilities. - Added a description factory to convert description items into classified containers. Tried to replicate WTE's description look as much as possible. - Left out documentation parsing. Will do this at a later date; however directive attributes rarely have documentation specific pieces that require parsing so we handle the 90% case. - Updated existing tests to reflect the new documentation mechanisms for RazorCompletionItems. - Added new tests to validate the completion source and the description factory. dotnet/aspnetcore#6364
VS Windows work has been mostly completed, waiting on two partner teams to get their bits to make it 100%. Starting VSCode work to get directive attribute support. |
- Updated `TagHelperDescriptorJsonConverter` to match what is in Razor. - Added the new completion item provider APIs to our list of services. - Created a new `Completion` namespace to hold off of Razor's various completion pieces. - Added a new completion item provider to provide `@...` when in a directive attribute compatible area when no text has been typed. - Partially moved the existing completion system over to `AttributeCompletionDescription`. There's more work that needs to be done here to be able to delete Razor.VSCode's description info types in favor of Razor's. - Expanded the completion endpoint to understand `Directive`s, `DirectiveAttribute`s and `DirectiveAttributeParameter`s. - Updated the `RazorDiagnosticPublisher` to handle cases when the underlying `RazorCodeDocument` has been garbage collected. Razor no longer caches these objects. - Added and updated loads of tests. dotnet/aspnetcore#6364
VSCode support in PR: aspnet/Razor.VSCode#367 |
- Updated `TagHelperDescriptorJsonConverter` to match what is in Razor. - Added the new completion item provider APIs to our list of services. - Created a new `Completion` namespace to hold off of Razor's various completion pieces. - Added a new completion item provider to provide `@...` when in a directive attribute compatible area when no text has been typed. - Partially moved the existing completion system over to `AttributeCompletionDescription`. There's more work that needs to be done here to be able to delete Razor.VSCode's description info types in favor of Razor's. - Expanded the completion endpoint to understand `Directive`s, `DirectiveAttribute`s and `DirectiveAttributeParameter`s. - Updated the `RazorDiagnosticPublisher` to handle cases when the underlying `RazorCodeDocument` has been garbage collected. Razor no longer caches these objects. - Added and updated loads of tests. dotnet/aspnetcore#6364
VSCode has been updated and insertion should be complete soon. |
Summary
Directive attributes is our term for built-in compiler features that look-like attributes, but don't map to any real HTML attributes or component parameters.
For instance
ref
looks like an attribute, but it does something that's intrinsic to the Razor language.You can think of these like macros.
We want to build a syntax for directive attributes (
bind
,onclick
,ref
) that allows more flexibility and can express more complex things than what we currently support. We are currently limited to the kinds of things tag helpers support.It would also be good to make these built-ins distinct in tooling and syntax from normal attributes.
Changes and design notes
Design notes are here: https://gist.github.com/rynowak/f2e6a4bfc3b685d7dce15d96942aa4b8
These are my raw notes and discussions with a few others so you may find things that are out of date there. When we ship preview 6 the docs will contain the authoritative info. Read my notes if you want to understand more of the motivations and minor decision points.
Directive attributes are defined as:
@{directive}(-{suffix}?)(:{name})(="{value}")
Examples:
Our built in directives:
bind
,onclick
(and other event handlers),ref
andkey
are being updated to make use of these new features. Most of the use cases are as simple as before.You'll notice how some of the parts that are defined by the syntax are used by these updated directives.
Key
Ref
Event Handlers
We wanted to make C# event handlers distinct from JS event handlers. It seems really tricky that a normal HTML attribute would do much more complicated things based on the value that's passed in. Also we're going to end up using more of the directive attribute features as we add power to event handlers.
note: we haven't implemented
stopPropagation
yet, but you can see that we have more options now.Bind
Out of scope
Extensibility of any kind.
Implementation steps:
bind:event
,bind-value:format
etc)bind:event
,bind:format
)bind:event
,bind:format
)@
prefix for directive attributesThe text was updated successfully, but these errors were encountered: