Organizing Component Properties?

Figma is really good at organizing and categorizing things using the " / "system. Is there anyway to organize component properties the same way? A lot of the components I am building have a lot of properties, and it feels cluttered.
Screen Shot 2023-04-18 at 12.40.59 PM

I really like how in the new nested instances feature you are able to minimize and have it exist in it’s own category. For more robust component building something similar would be really helpful in keeping our design panels clean.
If anyone knows if there is a way to do this please let me know! or Figma if you see this and could think about including a feature like this that would amazing thank you <3

1 Like

I think you’re already on the correct track! Leveraging nested components to handle properties is the first thing that came to mind when you mentioned wanting to group and collapse a set of properties.

Using the example screenshot you shared, what groups would you want to see? And what do you think about creating sub components to make those groups?

Being able to categorize properties by content would be very ideal. A lot of these builds that we make have right and left content separated by auto layout. So when making component properties we have these long names like " Right Content Icon 1" that usually gets cut off in the design panel. Being able to have a Right Content “folder” and put everything that belongs there will make it easier for designers to not have to click through every toggle to see which is the right one.
I thought about making sub components for the inner content of each component, just to have the same layout as the nested instances, but it seems like a lot of backtracking and an updating nightmare. The last thing I want is to clutter our design system, hence why we are using component properties to keep the variants at bay

I see, I think I follow you. Hmm… every team is different, so I hope this doesn’t land wrong when I say: my personal rule is that I should never optimize for component maintenance to the detriment of instance usability. Any time i don’t follow it I end up wishing I did. So with what you described, I would expect that sinking the time into building out those sub-components ends up being beneficial in the long run.

I would also (gently, encouragingly) challenge the idea that adding subcomponents would clutter the library! It sounds like you’ve thought a lot about the effects and tradeoffs of various build strategies, which to me suggests you’ve got the know-how to overcome the dilemma of keeping the file organized and clean. If it helps, a method I’ve seen from @Molly_Hellmuth is using sections to keep sub-components together, and adding a period or underscore prefix to prevent them from being published and misused elsewhere. Each sub-component should be exclusive to the published component it supports, even if two components need the exact same sub-component. This helps not create a tangle of dependencies. I often see this with things like labels. Wouldn’t say that’s a hard rule for all circumstances though.

It may be worth treating this like a little experiment. Maybe update just one component with this sub component method, publish it, and after a month chat with the team to see if it’s helped them work faster/more easily? That way you reduce risk of wasting time refactoring tons of components, and you and the team can get a more personal feel for when/where/if this approach jives with your system.