3 good practices when creating components for web/mobile apps.

Photo by Jash Chhabria on Unsplash

I’ve been working with component development and designing for almost 2 years, in those years i noticed some patterns that can make my job and the job of the people relying on my components easier.

Here are 3 good practices i use when developing components.

1. Standardize your prop names.

If you are developing a component that is similar to another one, it is a good practice to keep their prop names similar as well.

Suppose you are creating three similar components, they have their differences, but they share three props: label, onpress and value.

It would not make any sense to name those props:

• Component 1: ‘name’, ‘ontoggle’, ‘currentValue’
• Component 2: ‘title’, ‘onPressEvent’, ‘val’
• Component 3: ‘heading’, ‘onTouch’, ‘isActive’

In my line of thought, if a developer knows how to use one component, they should know how to use them all. The developer should not need to read the docs if he wants to use similar props across components.

2. Well-defined theming props.

I noticed something funny: Every component that have a “style” prop will deviate from its intended use.

When you less expect, that prop will be used to add margin and padding to the component instead of its wrapper or change the background color to Hot Pink.

When creating components, it is a good practice not to let the responsibility of theming to the team that uses the components, but to define a strict set of themes for your component.

For example, if we are developing a component that will be used with standard, error and highlight themes. It would be wise to create a prop only to define the theming you want and the inner works of the component would take care of the rest.

<SomeComponent theme="Error" />
<SomeComponent theme="Highlight" />
<SomeComponent />

The last call had no theming because “standard” is the default value of the theming prop.

While working designing and developing components, i noticed that keeping status and visuals strict can help you avoid problems with style in the future and keep your UI library “loyal” to the design system.

3. Pay close attention to the type of your props.

Suppose you are creating a component called ChecklistGroup. The purpose is to render and manage a group of checklist items. Naturally, we would separate the concerns and responsibilities of each element in that component.

• The ChecklistGroup would take care of the state, selection type (Multiple choices or single choice) and what happens when you check a box.
• The ChecklistItem inside the ChecklistGroup would take care of the label exhibited and the value of the checkbox.

With that in mind, what props should we use? What are the types would they have?

Another question: How would you design an input mask component that can have multiple mask types?

When creating components, the value we expect to receive from its prop is as important as the inner works of the component and deserve close attention to the type and default value.

I like to use this framework:

• Can the prop be activated/deactivated? Boolean
• Is the prop always active but have various values? String
• Is the prop quantitative? Number
• Is the prop an interface for a subcomponent? Shape (Please, don’t use object)
• Is the prop bringing code from anywhere outside the component? Function
• Is the prop a placeholder to render different component? Element

Final words

In short: It is good to develop a component call-focused.

If you were using that component, how would you like it to be called? Focus on the bare minimum of information that a component needs to work instead of customization potential.

Hope you liked it 😄