Skip to main content

Hi guys, I’d really appreciate it if you could help us with this challenge we’re trying to solve. To give some context: our current text field is a bit outdated. When we first created it, the way we handled things like auto layout and responsiveness was different, so now the auto layout isn’t working well. We also have duplicated variants because, back then, we solved the problem by creating a variant with an icon in the label and another without, as well as versions with and without an error state, and so on. Nowadays, we have the opportunity to optimize this. Instead of using these variants, for example, we are treating those differences as boolean properties.



One example of where we use this component is a large form on a page of our product. Each field is quite different from the others, with distinct content values and properties. We have several files, each containing multiple screens that use this component.



As I mentioned, we have many files that utilize this component, so we’re considering the best approach for making this change. We’ve thought about starting from scratch and manually replacing it, or modifying the current component being used, but neither option guarantees that we won’t lose the existing content or end up spending a lot of time on rework.


Do you have any insights or suggestions, or have you faced a similar situation before? I’d rather not have to change all the instances manually, but continuing to use the old component is not an option.

Hi @Luiz_Henrique


A year ago at my company, we had a single component—an input field with many variants and properties. It could handle text, numbers, multi-line, password, and more.

Initially we though having all these options in one component was a great idea, but it turned out it was not.

We found the component was hard to use—there were to many options, and we spent too much time navigating its properties to select the right configuration for the desired input-type.


When the variable system was introduced, we decide to break down the component into smaller, more specific ones. This is when we faced the a quiet similar problem.


After searching for a while, here’s what we ended up doing :



  • Not reusing the old component, we were concerned about losing design during a component update,

  • Removing the old component from our library, to prevent anyone mistakenly updating or using it,

  • Not replacing component in existing Figma files, with the new components. At my company, we use the product as the source of truth, so once a design in implemented in production, Figma files became less relevant. This might differ for you if you use Figma as your source of truth.


Hope it helped,


Hi @Haroll , thank you so much for your reply. Our cases do seem a bit different. Here, Figma serves as our source of truth, which influences decisions like the one you mentioned about separating the properties independently.


Out of curiosity, do you have any screenshots or supporting materials on how you approached your componentization? I’m curious to learn more about your strategy.


Reply