Prioritise the ability to iterate and evolve your UI
Build the skeleton and fill in the details from there
Make your Blazor app support deep linking by passing state in the Query String
Sometimes you'll want your Blazor UI to change according to the data you're using to populate it
Big feels overwhelming so start small and go from there.
Struggling to get "in" to a feature, or know where to start? Try sketching out a mockup.
Tailwind 3 automatically scans your site for html files, Blazor components, other templates in order to generate a static CSS file for your site, but it's a faff to launch Tailwind and your Blazor app separately...
The new Razor editor in Visual Studio 2022 doesn't currently provide intellisense for stylesheets you reference from external sources like NuGet packages…
Don't rush to break your UI down into separate components (too soon)
Consistency is key and make your components work harder to prove they're actually the 'same thing'
Ever spent hours trying to figure out why your app isn't working, only to spot the typo you made a few hours earlier?
Writing boilerplate API client code is deadly dull and repetitive, Refit will do it for you
There's no shortage of component libraries available for Blazor, but how do you figure out which one you should use?
Prerendering eradicates Blazor WASM's initial load time and .NET 6 addresses its one key limitation
Components are really useful for breaking down your UI into smaller pieces, and Blazor uses them extensively, but what if you're using Razor Pages?
Now your app supports dark mode, let's make sure your visitors only have to choose it once (or ideally, not at all)
Eyestrain is a real problem; help your users by adapting your site to their dark mode preferences
You know you should write more tests, but it's not that easy...
Because life's not complicated enough already!
You can render individual Blazor WASM components in your existing Razor Pages (or MVC) Core app.