Organizing Component Properties?

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.