Dynamic forms and validation in Blazor
By the end of day 3 we’d managed to get the Blazor application constructing a dynamic form based on an external set of defined fields (the idea being that a user could define those fields themselves using a future form-builder component of the application) and having those fields be validated dynamically on the client-side again based on externally defined validation rules. Here’s what that looks like:
The recording shows a user filling in some of those fields, whose values we can see are being bound to the underlying object, represented by the “current values” list on the right. It also shows two dynamic validation rules in action:
- When entering a first name of “Greg” the last name field becomes mandatory – this is an example of multi-field validation.
- When removing the first name that had been entered, the system demonstrates that the first name field is mandatory – an example of single-field validation.
Greg A and Ned continued working together to define the validation rule structure and then Ned and Greg H worked on integrating that into the Blazor application.
Client-side
Greg H extended the form state to include validation messages so that they could be displayed in the UI and also began working on rules for field visibility and enabled state.
Ned added some further field types (dates and numbers) and hooked the validation into the UI.
Server-side
Andrew completed setting up the components required to use the EventFlow framework including a Web API project using Swagger, which he chose because it really speeds up development time; offering many tools useful when designing an API and is quick to set up. That said, Andrew had included Swagger via a NuGet package called Swashbuckle for ASP.NET Core, which gets all the necessary Swagger components set up quickly, however he discovered that .NET Core 3 Preview 6 (which we’re using) will not work with the current stable release of Swashbuckle (4.0.1), so he switched to the pre-release of Swashbuckle 5.
Andrew also got the application persisting its events in SQL Server via Entity Framework, for now, until Julian can switch SQL Server out for Cosmos.
Speaking of which, Julian continued studying the configuration required to get an example EventFlow project running with Cosmos in preparation for switching our project over to do the same.