An Introduction from Jim

This is a sample project whose purpose is to show off both Blazor EditForms in a real working example as well as provide a use case to develop the SpiralAngle.Blazor.Extensions library.

1. This is intended to be a practical example of developing a Blazor WASM app. Most of the Blazor bits would apply equally to Blazor Server as well.
2. This is also intended to help find patterns that are useful in Blazor and then encapsulate them. That's part of the reason for the SpiralAngle.Blazor.Extensions library, but I expect to find back end patterns as well.
3. I work in Azure almost exclusively, so expect that things will take on that flavor. Right now, the only thing you'll see Azure specific is the Authentication Provider and that should only require some setup.
4. I'm also expecting to explore GitHub a bit more too. Dependabot and CodeQL are turned on for example.

As of the time of this writing, Game System list and edit screens are functioning and supporting multiple child objects in a single edit. The Blazor related code is almost trivial despite handling multiple child entities in a single edit. With some streamlining and templating, it can be even easier. The stuff that was a problem was:

1. Getting Entity Framework migrations set up (see below) in a way that didn't feel like I was compromising.
2. Dealing with EF in general. It's so cranky!
3. Authentication wasn't a bear because I copied all of the hard work from another project I've not made public yet. Seriously, pay attention to those bits in the README and go slow. Yeah, this is an opportunity for some automation.
4. Unfortunately, Blazor doesn't have a real live edit yet. That makes updating the Razor html templates a bit of drag when you get into the HTML needing some tweaking. When you recompile, it takes you back to the landing page. Fortunately, static pages (like app.css) can be updated without going back to the landing page. So, once you have the structure and CSS classes on the right elements, you can tweak the actual style w/out too much pain.
5. If you didn't pick up on it, just dealing with HTML in a non-trivial page. Microsoft, please bring XAML next!

What was pleasant:

1. Staying in the zone. No javascript or typescript means no context switching. All C# all the time!
2. No silly javascript build processes.
3. Base-10 decimals w/out drama. Yeah, I'm one of the miniscule number of developers that cares about this.
4. I learned a productive amount of Blazor in less time than it took me to learn an unproductive amount of PowerApps.
5. C# in the browser means we're free of the tyranny of JavaScript.
6. Single Page App development as easy as server side development. Wow.
7. Honestly, even the unfun bits couldn't take away the amount of fun this was so far.

My main take away: Blazor probably needs a bit of growing up still, but it's ok for smaller apps today. With a good set of accelerators, it will make web development easy again.

Please look at the README.md for getting started if you are interested in developing against this sample.

A video demo and walkthrough will be coming REAL SOON NOW.

If you are unfamiliar with Blazor, I highly recommend https://blazortrain.com/ for both the overview and some training.

If you're exploring the code, the main views with some interesting bits are GameSystemEditor and GameSystemList.

Backend is using Entity Framework with SQL server because I was a glutton for punishment and wanted to spend 60% of my time on Entity Framework and DB instead of Blazor. You know, because that was the goal. (Sarcasm!). About 20% of the time spent so far was solely on exploring an approach for handling Entity Framework Code First migrations in an external project without requiring the API project to know anything about that project. In other words, create an EF deployment project. Alright, only a couple of hacks. One: using an appsettings in that project for connection settings (it looks like support for --connection is coming so we won't need that). Two: Using a derived DbContext, CreatureMigrationDbContext, as a shim so that dotnet ef migrations can find a DbContext in the Migration project. This derives from the real DbContext, CreatureDbContext. See the README for more on that.

Next time I do a demo project I'll stick to CosmosDB or Blob Storage as I tend to just use whole objects anyway. :|

-- Jim