Up to here, the Kladde has had two faces that know nothing about each other: a prototype made of HTML files that you keep in sync by hand, and a web API that delivers data as JSON. In this module, the two grow together. The pages are generated on the server with Blazor, from components written in C# and HTML that use the same services as the API.
In this lesson you learn which kinds of Blazor there are and why the Kladde starts with the simplest. You read Microsoft’s template, learn
the Razor syntax and build Blazor into the Kladde’s host. At the end, the same process delivers JSON under /api/contacts and a page under
/contacts.
Where the Kladde stands
This module builds on the state after module 2.4. In the solutions, the Kladde looks like this:
Kladde.slnx
src/
Kladde.Core/ model and rules from K1: Contact, EmailAddress, Appointment, TimeRange, Result<T>, Error, IKladdeStore
Kladde.Data/ KladdeDbContext, the store implemented with EF Core, migrations (module 2.4)
Kladde.Files/ the JSON store from K1, only for the console now (lesson 2.3.1)
Kladde.Web/ the web API for contacts and appointments (module 2.3), BookingOptions,
the prototype in wwwroot (module 2.1), Styles/ with SCSS, Scripts/ with TypeScript (module 2.2)
Kladde.Console/ the console from K1
tests/
Kladde.Core.Tests/
Kladde.Console.Tests/
Kladde.Data.Tests/
Kladde.Web.Tests/
Since lesson 2.1.6, the stylesheet has been Styles/kladde.scss with its partials (_tokens.scss, _base.scss, _layout.scss,
_tables.scss, _forms.scss), and the build turns it into wwwroot/css/kladde.css. If your files, classes or folders have different
names, keep your names and carry the steps over. That’s not a mistake.