Building a frontend pattern library

At Hackney we’re currently in the process of rolling out a new design for our website. This has involved designing a UI Library of components that can be shared across other projects. Now we want to take those components and build them into a frontend pattern library so that code can also be shared across projects. We want this to take the form of an npm package that could be included in all projects so that styles, scripts and potentially templates could all just be imported individually from that package when required.

The starting point for our UI Library has been the GOV.UK Design System and many of our new Hackney components build on existing GOV.UK components with Hackney branding applied, often through changes to colour, font and/or spacing. Because of this I am keen to utilise the GOV.UK Frontend components in our frontend pattern library to avoid unnecessary work, duplication of code and to make use of all of the research and development that has already gone into GOV.UK Frontend. But if we are going to do that it also makes sense to use the GOV.UK Frontend wider setup (the Node.js app, Nunjucks templates, etc) as a basis for our Hackney Frontend; again this minimises duplication of code and effort and ensures maximum compatibility.

So the plan is to create an LBH Frontend repository that is very similar to the GOV.UK Frontend repository but also consumes the GOV.UK Frontend package so that its components can be used and built upon. The LBH components will all be prefixed “lbh” and these will be what are used by developers working on Hackney projects. Some components will be completely original and unique to Hackney, others will build on the GOV.UK components but with changes to markup (in which case we would rewrite the markup but utilise some GOV.UK classes) or styling. In cases where the Hackney component is very similar to the GOV.UK component, a component template could be as simple as including the GOV.UK component using Nunjucks and including an override class. There is a question about whether or not this last scenario provides value since that is something we could do without a LBH Frontend, but I think that establishing a set of LBH Frontend standard components that don’t require any modification feels like it is worth doing.

As Hackney is also doing a number of React projects it will also make sense to make a React version of the pattern library, similar to the GOV.UK React repository.

As both of these projects will be utilising GOV.UK Frontend we will need to have a plan for updating GOV.UK Frontend. Updates could include important accessibility changes, desirable new components, or crucial fixes so will be important to include. I think largely the plan will involve making sure that we are aware of GOV.UK Frontend changes and understand what has changed so that we can anticipate how this will impact LBH Frontend and build it into resourcing plans. I also think a Visual Regression tool such as BackstopJS would be useful in this instance so that we can automatically see any unexpected visual changes caused by updating GOV.UK Frontend.

Do you have any thoughts about this plan? I’d love to hear what you think. 

+ posts

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.