What makes a good UI component even better?
Outline of the article:
- Understand the designing of UI components
- Props of a UI component
- Naming conventions
- Clubbing multiple UI components
- Structure of utils
- Power of documentation
Introduction
The basic fundamental of building a UI component in React is that all primary components must be atomic in nature. The secondary components must be built by assembling the primary components. In the example below, the Legend table is a separate component that is being evoked by the RadialChart component.
Understanding the design
When working on a live project and catering to a large set of design requirements one must follow a uniform styling to make the UI more intuitive and easily navigable.
For example, rather than adding random spacing and padding in a button, all the buttons should adhere to the same styling format. When creating a UI component a developer must think like a designer. Yes, it might sound strange and people might think that design is the sole responsibility of the designer but it’s not. The developer must work hand in hand with the design team to make the design coherent. Many times the data flow in the product governs the user interaction thereby managing the UX of the product.
The ease for the end-user must be given higher priority than designing itself. Often, for making the design more appealing, flashy cards are added which might be taking up more space and not providing proportionate usability. The aim of any design should be to provide maximum product usability with the minimal user action.
Using friendly terminologies and providing info or tooltip for different buttons and user actions must be included as part of the designing process.
Primary components like texts, buttons, icons etc must be kept uniform across the design. Also, existing components must be broken down into smaller components to increase code reusability and also code readability.
Determining the props for UI components
The props for any UI component can be categorised into two categories:
- Generic props
- Specific props
Generic props: These are the props that must be present in all UI components. For example, all UI components must accept the class or className as a prop to override the styling when and if required.
Now, many people can argue that rather than having one prop for overriding styles we should have multiple props like margin, padding, width etc. as many components might not require other style properties to be changed. The justification for that stands on the principle of resilient design. When developing a component you cannot constrain your line of thought to the current design. Your components must be able to accommodate future design refactoring as well. Thus, UI components must be resilient and future proof.
Specific props: As the name suggests, the props are specific to the component that comes under this category. The overlap in the specific and generic props must be kept minimal. For example, if the colour has to be assigned to an icon, then it can be passed as a separate prop rather than as part of the styling class. Here, a developer-friendly approach must be taken.
Default values to the props must be provided wherever possible. These values must not be random; rather based on the overall design of the product the most frequently used values must be set as the default values of the props. This will help in rapid prototyping.
Naming conventions
The naming convention for the components and props must be kept in sync with the standard libraries. Many developers joining your team might have already worked on different components using well-known libraries. So if your prop performs a similar effect on the component, then naming it the same as that of well-known libraries makes it easier to grasp.
The name of the props should also be verbose. Gone are the days when developers had to type every letter in the code. Typing assistance and intelligence are provided by many code editors. Your name of the props should be precise and self-explanatory.
Clubbing multiple UI components
Enveloping multiple variations or states of the component helps reduce the number of components. For example, if you have separate components for the default button, info button, error button and disabled button then it will become a daunting task for the developers to memorize all of them. The better approach, in this case, will be to make a simple button component and pass on the states or variations as a prop.
Another good example is text, where rather than remembering all the sizes of h1 to h6 you have one Typography component in material-ui and you can pass the size as a prop.
This method will reduce the threshold for the new developers joining the team and thereby reducing the time to delivery of the product. As the time to market is very crucial, not only the components of the UI library but the local component should also adhere to such standard practices.
Structure of Utils
Maintain a separate utils folder for both the global level and component level. There will always be some utility function being used across different files of the same component so they must be added in the utility section of the component. Likewise, if some functions are being used across multiple components then they should be declared as part of the global utility folder.
Power of documentation
Documentation of the code is often neglected. Many times developers think that they remember all the code that they have added but once you revisit your own code after six months, you won’t understand half of the logic that you wrote. So all the functions and logic added in the code must be documented and comments should be added. Always remember that these comments won’t increase the size of the build, so feel free to add explanations wherever required.
UI practices at LitmusChaos
At LitmusChaos, we have adopted the best UI practices of the open-source community. Cultivating a culture of systematic UI designing and component development is a continuous process. We have developed the Litmus-UI library where we practise the component building approach for our complete frontend ecosystem. To learn more about the purpose of a UI component library click here.
Join our community on Slack for detailed discussion, feedback & regular updates On Chaos Engineering For Kubernetes,
To join, our slack please follow the following steps!
- Join the Kubernetes slack
- Join the #litmus channel on the Kubernetes slack
Check out the LitmusChaos GitHub repository and do share your feedback:
Submit a pull request if you identify any necessary changes.
Until the next article, Adios ❤.
