Posts

Deploy To Production

Image
  Continuous Delivery Options When launching anything into production, it's essential to eliminate any uncertain elements. This is where Continuous Integration and Continuous Delivery/Deployment (CI/CD) become relevant. GitHub Actions and Azure DevOps (or Azure Pipelines) are two Microsoft options for implementing CI/CD. There are numerous other alternatives, such as Jenkins, TeamCity, and GitLab - the options are extensive. If our current CI/CD solution is compatible with deploying ASP.NET, it will also be capable of managing Blazor since Blazor essentially functions as an ASP.NET application. We should ensure that we establish tests as a component of our CI/CD pipeline. The great aspect is that there is no requirement for additional hardware to test our components, it will function as long as our CI/CD pipeline can execute unit tests (nUnit, xUnit). We can execute all builds and tests whenever a pull request is made. If both the build and tests are successful, a team member condu...

Testing (Part 2)

Image
  Mocking The API We can implement the mock API in two ways. One option is to set up an in-memory database, but to maintain simplicity, we'll opt for the alternative and create posts on demand: Under MyBlog.Shared.Tests , right-click on the Dependencies node and select Add Project References. Check MyBlog.Shared and click Ok. Now our test project has access to all the classes in our shared project as well as all the classes the shared project is referring to, such as Interfaces in the MyBlog.Data.Shared project. Select the MyBlog.Shared.Tests project. Press Shift + F2 to create a new file and name the file MyBlogApiMock.cs . Add the following namespaces- using MyBlog.Data.Interfaces; using MyBlog.Data.Models; Implement the IMyBlogApi interface. For BlogPost , add code in the class. When we get a blog post, we simply create one and fill it with predefined information that we can later use in our tests. The same thing goes for getting a list of blog posts. The same thing goes ...

Testing (Part 1)

Image
  Introduction Conducting tests will enhance the product's quality since it ensures that previously functioning features continue to operate correctly. However, writing tests for UI components can often be challenging; the most prevalent approach is to launch the site and utilize tools that simulate button clicks, then analyse the results to confirm whether everything works as expected. The benefit of this approach is that it allows us to test our site across various browsers and devices. The drawback is that this testing process can be quite time-consuming. We have to launch the web application, open a web browser, confirm the outcomes of the test, close the web browser, and then repeat this for each subsequent test. We can apply this approach in Blazor in the same way as with any ASP.NET application, but Blazor offers additional options for testing. Steve Sanderson initiated a testing framework for Blazor, which was further developed by Microsoft MVP Egil Hansen. The framework cr...

Debugging

Image
  Debugging Blazor Server Right-click on MyBlogServerSide and click Set As Startup project. Press F5 to start the project. Using the web browser, navigate to https://localhost:5001/ throwexception (the port number may vary). Press F12 to show the web browser developer tools. In the developer tools, click Console. Click the Throw exception button on our page. Press F5 to continue and switch back to the web browser. We should now be able to see the exception message in the developer tools. Now let's try a breakpoint: In Visual Studio, open  MyBlog.Shared/Pages/Index.razor. Anywhere in the LoadPosts method, set a breakpoint by clicking the leftmost border (making a red dot appear). We can also add a breakpoint by pressing F9. Go back to the web browser and navigate to https://localhost:5001/ (the port number may vary). Visual Studio should now trigger the breakpoint, and by hovering over the variables, we should be able to observe their current values. Debugging Blaz...

Managing State (Part 4)

Image
  Using An In-Memory State Container Service In the context of in-memory state containers, we utilize dependency injection to maintain the service instance in memory for a specified duration (scoped, singleton, transient). To show how in-memory state works, we will have to implement it a bit differently depending on hosting. Implementing Real-Time Updates On Blazor Server In the MyBlog.Shared project, select the Interfaces folder and press Shift + F2 . Name the file IBlogNotificationService.cs. In the MyBlogServerSide project, select the Services folder and press Shift+ F2 . Name the file BlazorServerBlogNotificationService.cs . It might seem unnecessary to give the class a name that includes BlazorServer , but it makes sure we can easily tell the classes apart. In Startup.cs at the end of ConfigureServices, add the dependency injection- Services.AddSingleton<IBlogNotificationService, BlazorServerBlogNottificationService> (); We add this dependency injection as a S...

Managing State (Part 3)

Image
  Implementing WebAssembly We will use Blazored.SessionStorage for Blazor WebAssembly: Right-click on the Dependencies node under the MyBlogWebAssembly.Client project and select Manage Nuget Package. Search for Blazored.SessionStorage and click Install. Right-click on the MyBlogWebAssembly.Client project and select Add|New Folder. Name the folder Services. Select the new folder and press Shift+ F2 . Name the file MyBlogBrowserStorage.cs. Open the new file and replace the content with code. In the Program.cs file, add the following namespaces- using Blazored.SessionStorage; using MyBlog.Shared.Interfaces; using MyBlogWebAssembly.Client.Services; Add code just above await builder.Build().RunAsync();  Then we add our configuration for IBrowserStorage, but in this case, we return MyBlogBrowserStorage when we ask the dependency injection for IBrowserStorage. Implementing the shared We also need to implement some code that calls the services we just created: In the MyB...

Managing State (Part 2)

Image
  Implementing Browser Storage The web browser offers various methods for storing data, each with different handling based on the type utilized. Local storage is limited to the specific browser window being used by the individual. Even if the user refreshes the page or exits the web browser entirely, the data will remain intact. The information is also accessible across different tabs. Session storage is limited to the specific browser tab. If you refresh the tab, the data remains, but closing the tab will result in loss of the data. SessionsStorage can be considered safer because it minimizes the potential issues that could arise from multiple tabs altering the same stored values. To be able to access the browser storage, we need to use JavaScript. In .NET 5, Microsoft rolled out Protected browser storage , leveraging data protection features in ASP.NET Core, although it is not accessible in WebAssembly. Nevertheless, we can utilize an open source library named Blazored.LocalSt...