Design-system.Net

David Joseph
3 min readJan 2, 2021

I found myself at the start of a relatively long Xmas break (my employer gave us an extra week off) and I do love an Xmas Project (its ok I also ate chocolate, walked the Dogs, drank beer and watched many many Xmas movies). Previously I’ve refactored a classic ASP website into a best practice .Net Core API / Website with lots of loose coupling and best practices.

This year I thought I’d investigate how to implement a “Design system” as something that could be consumed by a .Net Dev with them worrying as little as possible about the implementation. So the ideal would tick the following boxes:

  • .Net native syntax
  • NuGet-able (able to be consumed via NuGet)
  • Updateable in one package / binary; in other words not too much ‘assets’ in the web project, as this would mean potential for files to be orphaned / amended by the person consuming.

Read on if you want the steps I went through and context but if you just want the conclusion / tl;dr feel free.

“Design systems” are everywhere the UK Government, Microsoft, Google to name just a few. I won’t justify the use of a design system here; there are others (UXDesign, Andrew Couldwell) who can and have done it better, but I would say that a key benefit is to stop the inevitable “drift” that happens when you have multiple websites (tens or hundreds) under a brand.
This is when the branding may be similar but not quite; meaning a cognitive shift for those users who look at multiple sites as well as the technical issues of multiple very similar but not identical pieces of code (the description of which would be another article in itself).

Ok, you say ‘I’m convinced, lets use a design system’. So first you’ll need your talented Designer(s) and front end Dev(s) to make your “foundations, components and patterns” or whatever you call your building blocks. Then you will need a way of implementing it in your preferred Language / Framework.

My colleague / talented front end Dev has implented our design system in “Nunjucks” (or rather is working his way through it); so my first thought was to see what my options were for using this from a .Net perspective. This led me to a few Nuget packages Nunjucks and Twig.AspNetCore (Twig and Nunjucks share a lot of syntax), but neither felt like they would be a good fit when making a .Net website.

However I really wanted something that a .Net Developer would find as straightforward as writing any view. So my second thought was ‘Tag helpers’ native to .Net and built to make custom HTML elements they seemed to fit the bill nicely. This failed when I realised that I’d need to have tags within tags to build patterns / more complex components.

Enter “View Components and Razor Class Libraries”; when used with Tag helpers these seem to fit the the bill.

  • Patterns can be wrote as View Components (but using tag helper syntax to keep it consistent).
  • Foundations and Components can be wrote as Tag helpers (more complex tag helpers can be wrote as view components).
  • and the overall design system can be implemented as a Razor class library.

Some of the advantages of this include being able to include all of the CSS, JS and image assets within the class library; they are copied at runtime to the project. We can also include the site template (“_Layout.cshtml”) the user will have to remove / not include theirs else it will override.

So how does this look? Well for a razor page using a component the below would be all the Dev has to write.

The ‘Code behind’ (not sure what else to call the Razor page codepage) looks like this.

And a Pattern / View Component is equally as straightforward.

And the implementation of the tag helper is fairly straightforward (bear in mind this is doesn’t include any huge amount of error checking etc but will as I move to implement the rest of the design system.

Thoughts? Is their a better way? or “this is the way”?

--

--

David Joseph

Web Dev, Daddy, Geek, He/Him. Believer in Magic Monks.