The hard part of a living design system, like Eufemia, is to avoid creating black holes and choosing ways to make maintainability hard and complex.
To make this more understandable, follow along this detailed explanation about the hard part of DNB UX's vision of maintaining future changes to accessibility, including design, diversity of thinking, future user experience evolution, alongside with DNB brand changes.
Now that we got a picture about what Eufemia aims to strive against, we will dive into more technical aspects on how to find solutions to support the system as it should.
It is vital that Eufemia integrations are made as easy as possible to maintain, update and be prepared for maintainability and future changes.
Eufemia is build upon using a tree shaped system pattern. Where one system uses a sub-system (or parts of it) in order to shape its full existence. E.g. the Button component uses the color system, spacing system, the typography system, a naming system (properties, file names) and the icon system.
Some systems are low level systems (like a naming system) and some are high level systems (like components). Both types of systems we thread as our building blocks.
Using the building blocks
Using the building blocks (sub-systems) as they are meant to be used, is an important part of using Eufemia. It is in fact a key factor of helping Eufemia to future develop and avoid friction and unexpected behavior changes.
Color system usage
In order to both serve ready to use components and make them as flexible as possible to be used, there are a couple of different concepts Eufemia is following:
- Helper pattern
- Property pattern (Web Components)
- Higher order component pattern
- Render prop pattern
- Hooks pattern
It will vary when and where these extensions are used. And some extensions, like the property pattern, is used by almost every component.
Overall, the reuse of existing adapters and APIs and using components for what they are designed for to be used, will allow Eufemia to be able to further develop and be maintainable.
The declarative paradigm
As we want to avoid creating applications with imperative programming styles, because of it's nature to make code hard to read and maintain, we encourage everyone to try to write code as declarative as possible.
Web Components usage
Global CSS and SCSS/SASS usage
We can start off by having one CSS class defined and declaring that in the HTML. Perfectly fine. But there will be no limit for us to manipulate our declaration from where ever. We can't read and see that from our CSS class. Suddenly, we entering a imperative programming style. Therefore other CSS tooling like would be preferable to be used:
- Styled Components (e.g. Linaria, Emotion, styled-components)
- Scoped Styles (e.g. Scoped Styles)
- CSS Modules
- Token based (e.g. style9, stitches)
Token based styling
A token based styling system has gained more attention the last years. And in fact, it is a highly declarative methodic with a low footprint, because of it's nature of reuse. The only downside is that it comes first to it's full potential, if both Eufemia and the applications would use that system.