Engineering Path

Introduction

In the previous chapter we introduced you to the contribution process, explaining how, when and where you should contribute. In this last chapter we are going to discuss what you should take into consideration when you decide to build a new component. We are going to suggest you best practises and guide you in order to achieve the same qualify of the already existing core component of the Mews Design System. Don’t forget that we always available not just for code review and also for more generic support and guidance.

 

---

Plan accordingly

Building a new component from scratch it’s not easy task and it does require attention to details and proper planning. First of all don’t just start building something as a solo effort but always have the involvement from your designer and follow the official process for contributing so create the documentation required and follow the steps illustrated in the contribution documentation.

When it’s finally time for you start coding the new component think about how the component is expected to be used and where. A collaboration with your designer is fundamental, because even if they considered everything, you have noticed in the codebase something new that requires something else to be taken into consideration when developing the component or even a similar piece of UI that already exists.

Also remember that a component should be agnostic and have the flexibility needed to be used by others, so plan the API accordingly and don’t build something too rigid. If what you are trying is going to be used just in your products then it should live in the B2B or GX workspace, but if you know already that are multiple teams needs it then it should live in the Core library. If this is the case involve other teams in order to build something useful for all the teams that need it.

Always keep out business logic from the component you are building. Even if the component is going to live in one specific workspace it should just be a pure UI component and don’t have any data in it. We highly recommend to have the component with the other components in the UI package in the mews-js repository. This helps discoverability, so other teams can see and use your component instead of writing something very similar, while keeping business logic far and detached.

 

---

Keep it simple

When building a component is easy to think too much about the possible use cases and wanting to cover future and unknown scenarios. This is a good intention for sure but can bring to very complicated components that are difficult to work with and maintain. You should consider what you are building as an initial version of the component, something that can always be improved once the usage is more clear or other engineers start using the component.

Keeping it simple means also don’t be too clever when writing the code and abstract too much. You might be very familiar with the component because you are creating it but then other engineers will have to use it and they might find the API too complex for example or finding that the component has been built in a very different ways compared to all the other components. We want to make the work easier for other engineers when they use our components so this should be taken into consideration.

Following the above point of simplicity and good DX you should avoid using third party libraries almost always. A library is usually not required when dealing with UI and it’s something that should be left as part of the component usage in the product. This helps massively with maintainability, because no dependencies apart from the standard ones make a component more robust and future proof.

We don’t want to try to reinvent the wheel when you start to writing code for your new component therefore please take inspiration from the other components that already exist in the Mews Design System. The component you are building should be structured in the same way anyway so keep styles and types in separate files, use named exports, write simple React and all this will help you shipping a components that you and other engineers find very easy to understand and use.

 

---

Consider everything

Even if you are trying to keep it simple when developing your new components there are still a lot of things to consider. Take your time thinking deeply about the API, double checking with your designer if everything got covered and going through the review part is a process that can easily take many days. As always we can support you not just during the review phase but even during the development process if you any questions to ask or you are stuck on something. Reach us in our support channel and we will do our best to help you.

The main thing to consider during the deployment of the component is how to present the component itself and make it discoverable and usable to and for others. Therefore you should spend a bit of time building an extensive story for the component. You can have a look at the codebase for other stories and how they render in any of the Storybook workspaces. Everything that is customizable in the component should have a control well specified where it very clear what kind of options are available. If the component has multiple variations you might even want create 2 stories, a playground one and an overview one without any control.

The nature of a design system component is to be flexible and usable in different scenarios. You should keep this in mind during the developing phase and it’s something you should test against. Is the component responsive and adapts to various viewports and types of content? Is the component accessible and users can use it without a mouse or via a screen reader? Are you using the correct tokens and not adding any custom colors or spacing value? Please check everything before submitting your work for review to avoid request for changes.

Going back to the discoverability you should not forget about documentation. If the component doesn’t live in the core workspace you are responsible for adding the technical documentation for you component. If you build something that other engineers find difficult to use because they don’t understand how or the example and API are not well explained then the component is like if it doesn’t exist. These last bits can seem tedious and feel almost pointless but are very important for sharing the great work you have done. Once everything is ready don’t forget to inform us and others of the availability of the new component so we can help you to spread the word.

 

---

Outro

In this last chapter we described the process of building a new component from the start to the end. There is a lot to take in but this is necessary for creating a component that is useful and usable not just by your team but also by others and follows the necessary requirements and has the same quality of the core components of the Mews Design system. When possible try to avoid creating a complex component or a component that does too many things. Keep it simple, take your time and follow the various steps and the information you can find available. If you have arrived at this point after reading all the other chapters you should have everything covered, and if you only reading this specific chapter maybe spend a bit more times on the others and as always get in touch with us for any help you might need.

 

---

Where next