Add Blazor partial class support in Visual Studio. #1182

NTaylorMullen · 2019-09-27T18:33:46Z

No longer mark declaration files as single file generators. Prior to this we relied on SingleFileGenerators to dynamically update the declaration files when .razor files changed. However, to make partial classes work we can no longer depend on declaration files being available because their existence causes us to have to mangle class names for opened documents; otherwise you get two files with same name and result in ambiguous definition errors.
Stopped including declaration files as part of the users compilation. This was intended to make the design time experience operate more similar to how Blazor apps function at runtime (directly access each component instead of their declarations). We now rely on the background code generation effort built from the find all references work to supply users with strongly typed component names.
Stop mangling class names for Visual Studio. Razor.VSCode has its own set of configurations which i'm not addressing as part of this changeset.
Start generating components with the partial modifier to their class name to enable partial class support.
Updated existing tests to expect partial modifier.

- No longer mark declaration files as single file generators. Prior to this we relied on SingleFileGenerators to dynamically update the declaration files when .razor files changed. However, to make partial classes work we can no longer depend on declaration files being available because their existence causes us to have to mangle class names for opened documents; otherwise you get two files with same name and result in ambiguous definition errors. - Stopped including declaration files as part of the users compilation. This was intended to make the design time experience operate more similar to how Blazor apps function at runtime (directly access each component instead of their declarations). We now rely on the background code generation effort built from the find all references work to supply users with strongly typed component names. - Stop mangling class names for Visual Studio. Razor.VSCode has its own set of configurations which i'm not addressing as part of this changeset. - Start generating components with the partial modifier to their class name to enable partial class support. - Updated existing tests to expect partial modifier. dotnet/aspnetcore#5487

rynowak · 2019-09-27T19:35:17Z

What's the user experience of this like re: switching context between files. Today when you, save, give focus to, or remove focus from a component file, it results in a chain of events that cause us to update component descriptors. This is critical for productivity - that you can add a [Parameter] in a component, and then immediate use it elsewhere.

NTaylorMullen · 2019-09-27T19:50:28Z

What's the user experience of this like

It's exactly the same as today with 1-2 known bugs that I plan to fix later:

If you add a [Parameter] to a partial class and then switch to an already opened component file you will not get updated TagHelpers until you start typing in the file.
There's a theoretical bug that I haven't seen rear its head but seems possible to me where if you open a Blazor project and the project system is quick enough to initialize then you may not get component bindings for already-open files. This is because it's possible that we don't do more than 1 parse for all the files in the project meaning we wouldn't get component descriptors. In practice this is incredibly rare / racey since our stuff seems to always initializes first. Again, super theoretical but something I want to verify is or is not an issue when i'm back from vaca.

rynowak · 2019-09-27T20:34:53Z

I'm worried about all of these things.

NTaylorMullen · 2019-09-27T20:49:48Z

I'm worried about all of these things.

I want and plan to fix them as well once i'm back from vaca.

rynowak · 2019-09-27T21:18:12Z

What are the fixes with these things? I'm nervous about steaming ahead without knowing what the roadmap is.

NTaylorMullen · 2019-09-27T21:22:44Z

What are the fixes with these things? I'm nervous about steaming ahead without knowing what the roadmap is.

For the first case Roslyn has already evaluated the document so we can look to see if the file is a component, if so re-trigger TagHelper completion.

For the second case we re-discover TagHelpers after a component has been parsed.

I haven't fully thought through each of the solutions above but there's a lot of ways we can fix either one of the probs

rynowak · 2019-09-30T23:23:38Z

We tested this kind of stuff out in realtime, and it works pretty well 👍

rynowak · 2019-09-30T23:24:15Z

src/Razor/src/Microsoft.AspNetCore.Razor.Language/Components/ComponentDocumentClassifierPass.cs

@@ -81,6 +81,7 @@ protected override CodeTarget CreateTarget(RazorCodeDocument codeDocument, Razor
            @class.ClassName = computedClass;
            @class.Modifiers.Clear();
            @class.Modifiers.Add("public");
+            @class.Modifiers.Add("partial");


Do we need to target this per-version? I guess not because it's not really a breaking change?

@pranavkm - @ajaybhargavb did we build a 3.1 versioning scheme into the SDK yet?

I think it's simpler for now if we just make this change happen to both 3.0 and 3.1 projects.

Don't think so. 3.0 is still the latest.

rynowak · 2019-09-30T23:25:35Z

src/Razor/src/Microsoft.VisualStudio.Editor.Razor/LegacyProjectEngineFactory_3_0.cs

-                var componentDocumentClassifier = b.Features.OfType<ComponentDocumentClassifierPass>().FirstOrDefault();
-                if (componentDocumentClassifier != null)
-                {
-                    componentDocumentClassifier.MangleClassNames = true;


Can we also remove support for MangleClassNames?

Yeah but there are some places it is used like in DefaultTagHelperBinderPhase so it will take some time to make sure removing it doesn't break that code. I'm going to address this as part of a new PR targeting preview3.

ajaybhargavb · 2019-10-01T02:34:54Z

Merging for preview2. Will address feedback in a new PR for preview3.

- No longer mark declaration files as single file generators. Prior to this we relied on SingleFileGenerators to dynamically update the declaration files when .razor files changed. However, to make partial classes work we can no longer depend on declaration files being available because their existence causes us to have to mangle class names for opened documents; otherwise you get two files with same name and result in ambiguous definition errors. - Stopped including declaration files as part of the users compilation. This was intended to make the design time experience operate more similar to how Blazor apps function at runtime (directly access each component instead of their declarations). We now rely on the background code generation effort built from the find all references work to supply users with strongly typed component names. - Stop mangling class names for Visual Studio. Razor.VSCode has its own set of configurations which i'm not addressing as part of this changeset. - Start generating components with the partial modifier to their class name to enable partial class support. - Updated existing tests to expect partial modifier. dotnet/aspnetcore#5487

NTaylorMullen · 2019-10-09T15:44:24Z

.../src/Microsoft.NET.Sdk.Razor/build/netstandard2.0/Microsoft.NET.Sdk.Razor.DesignTime.targets

-    For now we need to treat component files as if they have a single file generator. This will allow us
-    to trigger a workspace update for the declaration files when they change.
-  -->
-  <ItemGroup>


Shoot we need to make this dependent on > 3.0 projects. Otherwise if a user downloads latest VS it will not properly work with older projects.

- No longer mark declaration files as single file generators. Prior to this we relied on SingleFileGenerators to dynamically update the declaration files when .razor files changed. However, to make partial classes work we can no longer depend on declaration files being available because their existence causes us to have to mangle class names for opened documents; otherwise you get two files with same name and result in ambiguous definition errors. - Stopped including declaration files as part of the users compilation. This was intended to make the design time experience operate more similar to how Blazor apps function at runtime (directly access each component instead of their declarations). We now rely on the background code generation effort built from the find all references work to supply users with strongly typed component names. - Stop mangling class names for Visual Studio. Razor.VSCode has its own set of configurations which i'm not addressing as part of this changeset. - Start generating components with the partial modifier to their class name to enable partial class support. - Updated existing tests to expect partial modifier. aspnet/AspNetCoredotnet/aspnetcore-tooling#5487\n\nCommit migrated from dotnet/razor@ecb3b1b

- No longer mark declaration files as single file generators. Prior to this we relied on SingleFileGenerators to dynamically update the declaration files when .razor files changed. However, to make partial classes work we can no longer depend on declaration files being available because their existence causes us to have to mangle class names for opened documents; otherwise you get two files with same name and result in ambiguous definition errors. - Stopped including declaration files as part of the users compilation. This was intended to make the design time experience operate more similar to how Blazor apps function at runtime (directly access each component instead of their declarations). We now rely on the background code generation effort built from the find all references work to supply users with strongly typed component names. - Stop mangling class names for Visual Studio. Razor.VSCode has its own set of configurations which i'm not addressing as part of this changeset. - Start generating components with the partial modifier to their class name to enable partial class support. - Updated existing tests to expect partial modifier. aspnet/AspNetCoredotnet/aspnetcore-tooling#5487\n\nCommit migrated from dotnet/razor@73858cd

NTaylorMullen requested review from rynowak and ajaybhargavb September 27, 2019 18:33

NTaylorMullen requested a review from pranavkm as a code owner September 27, 2019 18:33

rynowak reviewed Sep 30, 2019

View reviewed changes

rynowak approved these changes Sep 30, 2019

View reviewed changes

ajaybhargavb merged commit ecb3b1b into release/3.1 Oct 1, 2019

ghost deleted the nimullen/5487 branch October 1, 2019 02:40

mkArtakMSFT added the area-blazor label Oct 1, 2019

ajaybhargavb mentioned this pull request Oct 1, 2019

Improve partial class support in Blazor dotnet/aspnetcore#14646

Closed

1 task

NTaylorMullen commented Oct 9, 2019

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add Blazor partial class support in Visual Studio. #1182

Add Blazor partial class support in Visual Studio. #1182

Uh oh!

NTaylorMullen commented Sep 27, 2019 •

edited

Loading

Uh oh!

rynowak commented Sep 27, 2019

Uh oh!

NTaylorMullen commented Sep 27, 2019

Uh oh!

rynowak commented Sep 27, 2019

Uh oh!

NTaylorMullen commented Sep 27, 2019

Uh oh!

rynowak commented Sep 27, 2019

Uh oh!

NTaylorMullen commented Sep 27, 2019

Uh oh!

rynowak commented Sep 30, 2019

Uh oh!

rynowak Sep 30, 2019

Uh oh!

rynowak Sep 30, 2019

Uh oh!

rynowak Sep 30, 2019

Uh oh!

ajaybhargavb Oct 1, 2019

Uh oh!

rynowak Sep 30, 2019

Uh oh!

ajaybhargavb Oct 1, 2019

Uh oh!

ajaybhargavb commented Oct 1, 2019

Uh oh!

NTaylorMullen Oct 9, 2019

Uh oh!

Uh oh!

Add Blazor partial class support in Visual Studio. #1182

Add Blazor partial class support in Visual Studio. #1182

Uh oh!

Conversation

NTaylorMullen commented Sep 27, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rynowak commented Sep 27, 2019

Uh oh!

NTaylorMullen commented Sep 27, 2019

Uh oh!

rynowak commented Sep 27, 2019

Uh oh!

NTaylorMullen commented Sep 27, 2019

Uh oh!

rynowak commented Sep 27, 2019

Uh oh!

NTaylorMullen commented Sep 27, 2019

Uh oh!

rynowak commented Sep 30, 2019

Uh oh!

rynowak Sep 30, 2019

Choose a reason for hiding this comment

Uh oh!

rynowak Sep 30, 2019

Choose a reason for hiding this comment

Uh oh!

rynowak Sep 30, 2019

Choose a reason for hiding this comment

Uh oh!

ajaybhargavb Oct 1, 2019

Choose a reason for hiding this comment

Uh oh!

rynowak Sep 30, 2019

Choose a reason for hiding this comment

Uh oh!

ajaybhargavb Oct 1, 2019

Choose a reason for hiding this comment

Uh oh!

ajaybhargavb commented Oct 1, 2019

Uh oh!

NTaylorMullen Oct 9, 2019

Choose a reason for hiding this comment

Uh oh!

Uh oh!

NTaylorMullen commented Sep 27, 2019 •

edited

Loading