New Blazor Rendering Mode Features in .NET 8.0

hey everyone Alex here at the code wolf again welcome back in today's video we're going to explore some additional new blazer features in the upcoming.net 8 release specifically we're going to look at the different rendering modes that are available when you're working with those new blazer server-side rendering capabilities we'll learn how to combine Blazer webassembly or Blazer server circuits with the new server-side rendering to achieve full stack development with just Blazer this means we'll see how to render page components on the back end while adding Rich client interactivity to the front end wherever we need it also please remember to hit subscribe to support the channel now as an important side note remember that Blazer server side rendering is a new and completely different thing than Blazer server which relies on websockets and signalr and has been a part of Blazer since the beginning if you aren't familiar with the new blazer server-side rendering pattern in.net 8 I have a video dedicated to just that topic in depth linked below that I'd recommend you check out first how however I'll also briefly review some of that info in this video where it makes sense so if you are already familiar with blazer in general you'll probably still be able to follow along without that video either way let's dive in and get started foreign [Music] for this video I'm using an example project provided by the.net team that is already set up to highlight different types of Blazer rendering models this sample project is also linked in the video description so just clone or download that and you'll be able to follow along over in Visual Studio code I have that project open so let's look at a few Concepts here first note that this app is divided into two projects one for the client and one for the server generally speaking if you plan to use Blazer server side rendering in combination with the other hosting models you'll want to put whatever components you want to render in the browser using webassembly inside the client project and components you want to render on the back end in the server project the reason we have two projects currently is because if you think about it the webassembly and server-side versions of your app are really two entirely different build outputs and compiled code bases webassembly runs in the browser while server-side components run on the server originally the.net team aimed to have a unified project structure where it could sort of adapt to the build targets and output to create both versions from the same project but as of.net 8 that is not fully implemented maybe we'll see that in net9 anyways let's look at the server project to start with specific typically the program.cs file inside here there are a couple of blocks of code we want to focus on together these Snippets handle three tasks they set up our server-side component rendering our Blazer server rendering using signalr and our webassembly rendering map Razer components is of particular interest to us at the moment since that's the code that registers the different routable components in our project for server side rendering a routable component is just any component in our project that includes the at page directory with a URL path set such as our weather component here Now by configuring all three approaches we can switch between any of these rendering options in net 8 seamlessly on a per component basis this is pretty cool of course you can also remove one if you don't want it such as removing the webassembly registrations if you don't want to support any webassembly functionality in your app at all we can see how this works in practice by examining the components in our project more closely first let's check out the home.razer page as you can see there's nothing all that interesting going on here except for that app page directive at the top because we have the new server-side rendering feature enabled for our project this component will be routed to and rendered server side when the home page is requested the rendered HTML markup will be sent to the browser as one complete response just like we've had for a long time in MVC or Razer Pages or really any server-side UI framework the same goes for our weather component here we just have a slash weather endpoint and that will make sure this component is rendered out on the server things start to get a little more interesting if we open up the counter component now notice that this counter component actually references another counter component that lives in the client project that's because the counter component in the server project is just a placeholder that wraps the counter in the client project as of.net 8 preview 7 you you can't directly navigate to components in other project assemblies as this comment explains in a near future release we should be able to exclude this wrapper component and just reference the counter that lives in our client project directly anyway the main point of Interest here is the render mode attribute on the client counter component the render mode tells Blazer which type of rendering to use for that component that's right if we want to add more Dynamic interactivity out of per component basis we can now specify whether to use webassembly or Blazer server with signalr circuits right now this is set to Auto but for now let's change this to render mode.server to make it easier to demonstrate some Concepts then let's run the app to inspect how all this behaves in the browser once the site loads let's open up our Dev tools to inspect this a bit closer under the application tab let's first make sure to clear out our site data then let's switch to our Network Tab and enable the websocket filter first and then let's refresh this page notice how there's actually no activity at all on the websocket tab our component was completely rendered server side and then sent back as a complete HTML response again similar to what we had in the past with Razer Pages or MVC it's not using webassembly or signalr like in the traditional Blazer server hosting model and if we click over to the webassembly filter there's also no activity there either because none of our components are even set up to use webassembly right now we can see this same behavior if we switch over to our weather component even though this page retrieves data that was also all done server side without any Rich interactivity setup with the browser well now let's see what happens if we click over to our counter component and there it is immediately we see a Blazer circuit was set up to the back end process that's hosting this app as we click the button the counter goes up and those updates are all happening over this new blazer circuit now let's switch over to vs code and see what the same scenario looks like if we switch this component to instead use rendermode.webassembly so I'll change that quick and then let's stop the app and then use.net run to launch it again after that loads in the browser again make sure to clear your site data over in the application tab of the dev tools and clear out any history in the network tab for a fresh start then let's refresh the home page and sure enough still no websocket or webassembly activity on the home page the same holds true if we navigate over to the weather page again as well still no activity on either however let's see what happens this time when we click on the counter component sure enough there's no websocket activity this time but under our webassembly tab we can see a whole set of resources was downloaded in order to execute this component in the browser using webassembly now thankfully basically all of these resources get cached for subsequent requests so if we clear this out and then keep refreshing the page you can see there's no additional resource requests however we can still verify over in the console tab that the webassembly loader is indeed at work to render this page now if we switch back to vs code there's also a setting available called Auto which is what the project was configured for originally Auto is unique in the sense that it will decide automatically for you whether to use Blazer server or webassembly to render this component for example if the user has not yet downloaded all of the Blazer webassembly assets it will start up a Blazer circuit first to render the component since that's quicker for the first time load and then it will still download the webassembly assets in the background on subsequent requests from then on it would load the page initially using webassembly since the assets would already be there then one other thing I want to point out is that you can actually Define the render mode in the component itself rather than setting it as an attribute where it's referenced like we are here so for example if I were to open our weather component which remember is being rendered entirely server side right now we can actually explicitly set this component to use Blazer server rendering with signalr in our circuits instead we can add an attribute at the top here for a server render mode so that anytime this component is routed to or rendered from another component it will always use Blazer server let's run the app to test this out back on our homepage in the browser network tools we can again see the page loaded as usual without any use of webassembly or Blazer server signalr circuits however this time when we click to our weather page now we can see a Blazer server circuit was spun up to render this page over signalr thanks to that attribute we added the Blazer server hosting model we've always had in Blazer is now at work here so at this point you might still have a lot of questions can we still create Blazer projects entirely in webassembly or Blazer server and just ignore all this new server-side rendering can we switch between these options after we've started a project can we upgrade existing projects to.net 8 without worrying about any of these new features and perhaps most importantly how and when do I decide which rendering modes or hosting models to use well let's start with the short answers first yes in.net 8 you can still create Blazer projects that are entirely based around webassembly or Blazer server with signalr circuits just like you always have no worries there and yes you can always change your architecture later also yes you can also just version bump upgrade all of your existing projects to dot at 8 without any breaking changes in terms of choosing a project rendering or architecture approach going forward you have a few options here if you want your site to be entirely client-side and able to be statically hosted a full webassembly approach is still a valid and supported option however in many scenarios you may want to consider a new hybrid or full stack architecture like we just looked at built around server-side rendering this approach gives you that full stack solution with a lot of flexibility you can quickly render your main or core page components on the server without webassembly download times or a signalr dependency then you can just start choosing on a per component basis when to add rich interactivity as you need it using either the webassembly or Blazer server hosting models or both visual studio and net will also provide out of the box starter project templates for both of these scenarios so I hope this clarifies a lot of what's going on with the Blazer rendering in.net 8. please hit subscribe to support the channel and I'll see you next time

Channel: The Code Wolf

Views: 3,071

Keywords: Blazor .NET 8.0, Blazor, Blazor Server Side Rendering, Blazor Server Side Rendering .NET 8.0, Blazor Server Side Rendering WebAsembly, blazor tutorial, Blazor .NET 8.0 hosting models, blazor hosting models, Blazor Server Side Rendering vs WebAssembly, ASP.NET Core Blazor .NET 8.0, ASP.NET Core 8.0 Server Side Rendering

Id: VDyN8SnevzI

Length: 11min 4sec (664 seconds)

Published: Mon Aug 14 2023