Dev Camp 2019 – Day 2

Luke Canvin

Now well set up with our tasks the team spent day 2 making progress in each of their areas.

Shared code

One of the attractions of Blazor as a web development framework is that a common language is run both client and server-side. This has the advantage of meaning developers only need to know that one language to become quickly productive in writing code for both sides, but also code can be shared between the two. As well as some basic domain objects, of particular interest to us is validation logic.

Sharing validation logic in a Blazor project

In an ASP.NET MVC project, server-side validation would be written in C# and client-side validation would either need to manually replicate the relevant parts in JavaScript, or a tool would need to be written to generate JavaScript from the C#, or perhaps even a web-service to asynchronously call to validate on the server before the form is submitted. All of those methods are costly and introduce the risk of bugs or discrepancies.

In a Blazor project, the same validation code, written in C#, can be executed both client-side and server-side – no duplication of code, no risk of discrepancies.

This would be reasonably straightforward for a traditional web app with hard-coded validation rules on its shared objects, however because the forms we’re loading are defined in data, including the validation rules, our validation needs to be constructed dynamically and so today Greg A and Ned started work on the basics of the shared validation design.


Greg H fleshed out the basic Blazor form components, added application routing so that we could load multiple distinct pages, and created the form state object connected to the fields of the form. This involved working with mixed collections of generics, which wasn’t a straightforward experience, but if it has to be done, Greg recommends starting with a non-generic base type.

Ned merged his initial field type components (text, select, radio) and added data binding. He discovered that nested binding was a challenge in Blazor and so we’re doing that manually for now, although he and Greg have discussed some alternatives if we have time later. Ned then carried on implementing further field type components including a file uploader, which required use of Blazor’s JavaScript interop, which had concerned him, but in the end it was pretty painless.


Julian and Andrew continued work on getting the example EventFlow project working with Cosmos DB but with little success. Julian also investigated a non-EventFlow project that used Entity Framework to connect to both Cosmos and SQL Server, which appeared to work correctly so went back to debugging the EventFlow project.

Andrew continued work on the application project, implementing the components required by the EventFlow framework. This turned out to be a laborious process, although each component is not complicated, the number of components and their architecture is reasonably complex so takes time to put together. By the end of the day all the components were present but not yet hooked up to either the persistence layer or the client.