-
Notifications
You must be signed in to change notification settings - Fork 10.2k
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
Make autogenerated BlazorComponent views partial class #5487
Comments
You can use the However I agree with you that |
Yes, I know, in fact for now I'm proceeding this way. But to simplify the navigation of the project (for example through intellisense), I would prefer not to have basic classes that for now that are not useful for the project. |
Yeah, I agree with @uazo - I think partial makes a lot more sense for the Blazor use case. There's no reason not to just do this. |
Is there any possiblity to expect support for the View class to have the ability to be used as Generic class, WPF, Silverlight, UWP none of them support this, however this helps us to swap the view or the model depending on the scenario.
An extenral constructor can decide, what the view and viewmodel will be depending on the scenario. Since Blazor only supportes typed binding (other XAML technologies support reflection based also), I think supporting Generics when generating partial class is a must. Please try to consider this scenario when implementing. Otherwise we have to duplicate Views and viewmodels for small changes. |
@vibeeshan025 Could you write up your idea as a separate issue? Importantly, can you phase it in terms of a specific scenario example? Rather than saying the types should be generic, could you give an example based on some business scenario like "editing a list of products", and sketch out what sort of code you would want to work? It's difficult to evaluate it otherwise. Thanks! |
@SteveSandersonMS , thanks, I will write-up a separate issue. |
I'm interested in becoming a contributor to Blazor and came to see if this exact feature had been proposed. Is this feature available to be assigned to a new contributor? |
This is a really simple change to make in effect and there's already a PR for it actually. dotnet/blazor#294 Unfortunately this will totally break the editing experience, so totally blocked until we can figure out a solution to that. |
What is this? WinForms? |
@rynowak Can you explain what you mean by "this will totally break the editing experience"? Is it something with intellisense? |
Sure, when running in the editor, the component generated code has a mangled class name. This is needed to work around the fact that that the generated code also exists in the project with its original unmangled class name. When you reference a component by type in your C# code this works because the generated code exists in the project with it's original unmangled class name. If you allow the generated code to exist in the project twice with the same class name, then you will get lots and lots of errors at edit time due to duplicate definitions. If you allow users to create a 'code behind' partial class, then it that will match up fine with the generated code with its original class name, but not with the editor's version, which mangles the name. So you'll get errors in the editor for everything defined in the partial class. The solution is to fix the underlying problem, we don't have a mechanism to control the how the editor interacts with code already in the project. We're trying to address that for VS 16. |
Depends on #4065 |
Such partial classes would also allow to specify generic constraints easily when using |
- 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
- 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
@ajaybhargavb should this be resolved as |
Yeah. I'll file a new issue to track addressing feedback and fixing bugs. |
- 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
Filed #14646 |
I would like to split the Razor c # + html template from the purely functional code of the view and I tried to make every generated class contained in "BlazorRazorComponents.g.cs" with the partial modifier (simply adding it in "Microsoft.AspNetCore.Blazor.Razor. Extensions \ BlazorRazorEngine.cs ").
So my views are composed in
nomeview.cshtml <- html layout
nomeview.cshtml.cs <- functional code
The compilation works without problems.
The problem is Visual Studio is unable to "read" the contents of the code in cshtml.cs, showing the error CS1061 'Class' does not contain a definition for 'Method'.
Now, adding the directive
@inherits <name of the same class>
instead Visual Studio works correctly, while, obviously, the compilation is not successful because the autogenerated code becomes
public partial class <classname>: <classname> <- the same
But if the code remain
public partial class <classname>: BlazorComponent
both the compilation and Visual Studio would work.
Is it possible to make that if implements the same class, BlazorComponent is kept as a base class?
The text was updated successfully, but these errors were encountered: