Frontend Components Advice
Background
When Sirius was originally built it was made in Angular and used a set of bespoke components with a very low level of accessibility, performance and maintainability. As part of our general strategy we’ve been slowly cutting over to new micro-frontends based on GDS Design system components. There is some nuance within that strategic aim in terms of what is available and how it can be used.
GDS Design system Components
Newer frontends in Sirius should make use of the GDS Design system where possible for general layout patterns, typography and components. This helps with consistency and familiarity for users and quality for developers.
There are several reasons for this.
- By using the GDS components we get a higher level of baked-in accessibility and usability based on a high level of research and testing with users.
- We don’t have to reinvent the wheel for common components, saving ourselves time and effort
- We don’t need to design and maintain the components, also saving ourselves time and effort
- They follow tried and tested patterns for performant, server rendered components
There are some disadvantages though.
- Some of the GDS components are designed to fit with “one thing per page” citizen-facing service, this means they might not be 100% suitable for all our use cases on high-reuse internal systems.
- Some components just don’t exist in the system, sometimes for good reasons like poor practices (Carousels for example), but sometimes because they are not a commonly required use case for end-user services.
- GDS components are updated slowly, which means you may need to modify one for local needs
MOJ Pattern Library Components
In addition to the GDS Design system we also have the local MOJ Pattern Library, which extends the GDS system to provide some more components that have proved useful. MOJ Frontend is:
- Generally more regularly updated
- A smaller community of users and maintainers
- More focused on components used in internal-facing systems
This means that it should be our second choice for components if one that is suitable is available.
Note that components in the MOJ Pattern Library are occasionally promoted into the GDS system or replaced by equivilent components (like the Pagination Component). So you should put in a TODO or ticket to periodically check on if this has happened.
Custom Components
Where there is a need we can also build our own components. This has:
- A higher cost of ownership and maintenance
- Can solve problems only we have (at the moment)
- Can solve our specific problem, not a general one
- Requires more and closer work with design in the early stages of implementation to avoid accessibility or usability issues
These can be a fallback for problems unique to our system or where we have a particular user need to fulfil. Though in the longer term it is best to genericise these and promote them up to the MOJ Frontend to allow others to gain the benefit, in the tradition of “make things open it makes them better”.
As with other components, you may find a GDS or MOJ pattern is added later that covers a given use case.
General Strategy
As such our general strategy for frontend components can be summarised as:
- If there’s a GDS component that is suitable, use it.
- If there’s not a GDS component check the MOJ Frontend for one that’s suitable
- If there no suitable component, build it ourselves
- Pay close attention to the usability, markup patterns and accessibility of any new component we build
- Promote that component up to the MOj Frontend if it gets used repeatedly
Use core HTML
Although this is mainly concerning components you can use from off-the-shelf design systems, it’s worth noting that if you do need to build your own, please check for a standard HTML element first.
Modern browsers have a much larger set of built in UI and form components than they historically did as well as attributes that allow a lot of customisation for issues like validation. Don’t make your own progress bar if you can use a progress element for example.
Some standard UI components can be misused easily though, so consider the use case. An HTML number input is not a suitable element to handle a phone number, for example, due to the way some browsers handle non-numeric values like spaces in these.