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
We want to avoid creating applications with imperative programming styles, because of its nature to make code hard to read and maintain. We encourage everyone to write code as declarative and functional as possible. Parts that belong together, should naturally be kept close to each other, but still as small independent, encapsulated blocks.