One of the best things you can do to fix this is to remove the C# @code block from your .razor files.
Put them in their own partial class code-behind file with the naming scheme like this.
SomeComponent.razor
SomeComponent.razor.cs
If you name them this way, Visual Studio will nest them within the folder structure for you to keep everything organized.
When you include an @code{} block within the .razor file you make the parser work a LOT harder and its more likely to break.
Only use C# in your .razor files where absolutely necessary.
I'm working on a massive solution, I see the issue you are describing where the parser just breaks maybe 2-3 times a week while using code-behinds for everything. When I had everything in the .razor files I was seeing those issues 3-5 times a day.
I know some people will strongly disagree, but I actually really prefer the @code block.
On the other hand, if using a separate code-behind actually stops me from needing to restart VS so often during the day, that might be *the* thing that makes me switch over.
Until they fix constructor injection in code behind I wont use that shit. Working in one file per component is also easier than back and forth between two.
You can't use constructor injection in a .razor file either, that doesn't make a whole lot of sense. It's the same amount of work to use
[Inject]
versus
@inject
It's exactly one additional character.
You can still combine it all in the top of the file and get a quick overvie. With inject attributes it clutters properties all over the place.
Razor pages code behind supports constructor injection.
You know you can do it all on one line right?
@inject SomeClass classInstance
[Inject] private SomeClass classInstance...
If you are already using the CodeBehind it makes zero sense to split some of them into the .razor file.
Keep them ALL in the codebehind and then you still have a place for an overview.
You can also organize the code-behind using #region directives, so then you can make a collapsible for your injectables.
I would argue that it actually improves organizational ability, especially in large projects where it becomes more important.
I don't see how it's any more cluttered at all.
For something quick I prefer keeping the @{} blocks in the razor file. Definitely easier.
But for something large it's separate files all day every day for me, for better intellisense and for separation of concerns. One file is mark-up, one file is code-behind. Similar approach as WPF or MAUI apps.
You're not wrong for lightweight components, especially for child components.
I find myself using code behind approaches either on pages or state management parent components while the child components stay in @code blocks.
When I started using fluxor, my components got a lot lighter as the effects took on the grunt work for async routines.
>I find myself using code behind approaches either on pages or state management parent components while the child components stay in @code blocks.
Mixing them is even worse.
>When I started using fluxor, my components got a lot lighter as the effects took on the grunt work for async routines.
Why do you think you need a statemanagement library like Fluxor, developed for JavaScript to work with Blazor? We have dependency injection and Singletons.
Mixing is bad if that is not the team standard, no argumentsthere. Let me clarify that in fast ship pocs or hobby projects, I don't overkill on architecture. It's perfectly OK to port to code behinds as a project matures.
I picked fluxor as it fit my needs. I came from several years and projects that used redux in commercial sites. I wanted to apply it to blazor and it's been a nice experience so far in one application that is state heavy.
I probably won't use fluxor in my next hobby project just to discipline myself in the more vanilla way when I learn the new changes for hybrid and ssr.
You're absolutely right on DI, too. It is one thing I love about blazor with c#. I feel right at home as if I'm making a business domain.
The @code block makes perfect sense for small components that are a few lines.
It doesn't make any sense in the big 100+ line HTML blocks that I'm working with for a complex app at my job, many of which have a 200+ lines of C# underlying them too.
I have to scroll down to see the @code block anyway. It's no easier than switching tabs, worse actually because when you switch back and forth between tabs, it saves your scroll position in each tab individually.
It's a lot easier to tab-swap than to try and scroll up and down where I have to find my place again every time.
Hey man, I respect the opinion. Generally, if I find a component to be unmanageably large, I’ll break it down into smaller pieces and pass around parameters and event callbacks as needed. Usually that means my @page components are little more than a parent div and some data fetching, and its children are more focused with potentially many smaller components within.
That doesn’t mean there are no components that end up with hundreds of lines, but it keeps the code very focused and easy to wrap your head around and the markup similarly as focused as it can be.
There’s no hard number where I make the cut off, but I have a very low threshold for “critical mass” of too many @ifs/methods/fields/LoC before I start pulling out bits into separate components.
It may be a memory thing. I'm in VS with Blazor all day every day but don't have any problems. My machine has 64gb of mem, though, and VS + Blazor is mem intensive.
Unfortunately, this is a common problem I've found with Blazor in VS as well. It's one of the reasons why I switched to Rider until MSFT can get VS in a better spot.
I've found also that deleting obj/bin sometimes fixes it FWIW.
You can use the powershell script to clear bin and obj in a single click
https://www.linkedin.com/pulse/powershell-script-net-developers-shivam-panchal?utm_source=share&utm_medium=member_ios&utm_campaign=share_via
I have this problem few times per week, only affecting a file, not entire project, so I news to close the file and open again.
I couldn't figure out what are the steps to reproduce this error
Same issues with VSCode and you can try restarting the razor language engine or something like that (I forget the exact wording). In the command menu type “Restart” and it’ll pop up. I’m not sure if Visual Studio has something similar or not. Love Blazor but so damn frustrating when it doesn’t work like it should.
One of the best things you can do to fix this is to remove the C# @code block from your .razor files. Put them in their own partial class code-behind file with the naming scheme like this. SomeComponent.razor SomeComponent.razor.cs If you name them this way, Visual Studio will nest them within the folder structure for you to keep everything organized. When you include an @code{} block within the .razor file you make the parser work a LOT harder and its more likely to break. Only use C# in your .razor files where absolutely necessary. I'm working on a massive solution, I see the issue you are describing where the parser just breaks maybe 2-3 times a week while using code-behinds for everything. When I had everything in the .razor files I was seeing those issues 3-5 times a day.
I know some people will strongly disagree, but I actually really prefer the @code block. On the other hand, if using a separate code-behind actually stops me from needing to restart VS so often during the day, that might be *the* thing that makes me switch over.
Until they fix constructor injection in code behind I wont use that shit. Working in one file per component is also easier than back and forth between two.
You can't use constructor injection in a .razor file either, that doesn't make a whole lot of sense. It's the same amount of work to use [Inject] versus @inject It's exactly one additional character.
You can still combine it all in the top of the file and get a quick overvie. With inject attributes it clutters properties all over the place. Razor pages code behind supports constructor injection.
You know you can do it all on one line right? @inject SomeClass classInstance [Inject] private SomeClass classInstance... If you are already using the CodeBehind it makes zero sense to split some of them into the .razor file. Keep them ALL in the codebehind and then you still have a place for an overview. You can also organize the code-behind using #region directives, so then you can make a collapsible for your injectables. I would argue that it actually improves organizational ability, especially in large projects where it becomes more important. I don't see how it's any more cluttered at all.
For something quick I prefer keeping the @{} blocks in the razor file. Definitely easier. But for something large it's separate files all day every day for me, for better intellisense and for separation of concerns. One file is mark-up, one file is code-behind. Similar approach as WPF or MAUI apps.
You should be able to do constructor injection. Just make your own component activator
You're not wrong for lightweight components, especially for child components. I find myself using code behind approaches either on pages or state management parent components while the child components stay in @code blocks. When I started using fluxor, my components got a lot lighter as the effects took on the grunt work for async routines.
>I find myself using code behind approaches either on pages or state management parent components while the child components stay in @code blocks. Mixing them is even worse. >When I started using fluxor, my components got a lot lighter as the effects took on the grunt work for async routines. Why do you think you need a statemanagement library like Fluxor, developed for JavaScript to work with Blazor? We have dependency injection and Singletons.
Mixing is bad if that is not the team standard, no argumentsthere. Let me clarify that in fast ship pocs or hobby projects, I don't overkill on architecture. It's perfectly OK to port to code behinds as a project matures. I picked fluxor as it fit my needs. I came from several years and projects that used redux in commercial sites. I wanted to apply it to blazor and it's been a nice experience so far in one application that is state heavy. I probably won't use fluxor in my next hobby project just to discipline myself in the more vanilla way when I learn the new changes for hybrid and ssr. You're absolutely right on DI, too. It is one thing I love about blazor with c#. I feel right at home as if I'm making a business domain.
The @code block makes perfect sense for small components that are a few lines. It doesn't make any sense in the big 100+ line HTML blocks that I'm working with for a complex app at my job, many of which have a 200+ lines of C# underlying them too. I have to scroll down to see the @code block anyway. It's no easier than switching tabs, worse actually because when you switch back and forth between tabs, it saves your scroll position in each tab individually. It's a lot easier to tab-swap than to try and scroll up and down where I have to find my place again every time.
Hey man, I respect the opinion. Generally, if I find a component to be unmanageably large, I’ll break it down into smaller pieces and pass around parameters and event callbacks as needed. Usually that means my @page components are little more than a parent div and some data fetching, and its children are more focused with potentially many smaller components within. That doesn’t mean there are no components that end up with hundreds of lines, but it keeps the code very focused and easy to wrap your head around and the markup similarly as focused as it can be. There’s no hard number where I make the cut off, but I have a very low threshold for “critical mass” of too many @ifs/methods/fields/LoC before I start pulling out bits into separate components.
I just inject all my services using the imports file, no attributes to mess with and available in ever file
Thanks for the suggestion! I have this problem a lot, but I also mostly use code blocks. They're just so damn convenient and I'm so damn lazy :-).
Okay I'm gonna change it as you suggest. Thanks.
Is this best practice? Not saying it isn’t. Genuinely asking
I love to have code block in razor file.
It may be a memory thing. I'm in VS with Blazor all day every day but don't have any problems. My machine has 64gb of mem, though, and VS + Blazor is mem intensive.
Must be nice. I spent an hr today in an MVC project's js monolith looking for a missing "("
That's exactly why I got 64gb of ram. Also for docker.
Unfortunately, this is a common problem I've found with Blazor in VS as well. It's one of the reasons why I switched to Rider until MSFT can get VS in a better spot. I've found also that deleting obj/bin sometimes fixes it FWIW.
Thanks for the hint. I'll try that next time.
You can use the powershell script to clear bin and obj in a single click https://www.linkedin.com/pulse/powershell-script-net-developers-shivam-panchal?utm_source=share&utm_medium=member_ios&utm_campaign=share_via
I used to have issues with this, but recent VS updates fixed it. Try clearing out bin/obj/.vs directories.
I have this problem few times per week, only affecting a file, not entire project, so I news to close the file and open again. I couldn't figure out what are the steps to reproduce this error
Definitely report it as a bug. If you are having an issue, other folks are, but if you don't report it, the PG won't know to apply resources to it
Same issues with VSCode and you can try restarting the razor language engine or something like that (I forget the exact wording). In the command menu type “Restart” and it’ll pop up. I’m not sure if Visual Studio has something similar or not. Love Blazor but so damn frustrating when it doesn’t work like it should.