Skip to main content

With the new update, we have a great new feature, but unfortunately, it’s not usable with our component structure.

Exposing all props of a nested instance also exposes props that we don’t want in the context of the consuming component.


What if we could also select which properties to expose? This would lead to a cleaner sidebar with only valid props.


This is really important to make nested components usable…


Want to add another important point in this regard:


🆕 Make the exposed properties addable to the main component so they can be sorted manually in between the original components properties (distinguishable by a small icon/dot/whatever).


I like this idea as well. The workaround for me was breaking variants into separate components to prevent user error when using nested instances.


Desperately want this please!!


This would be really helpful. @Mel_Bosch and @Brian_Heston are spot on.


Please give this to us 🥺


+1


A must have!


Another vote in favor of this capability. It would be a huge unlock in terms of balancing the power/scalability of a design system with its usability.


A current (and relatively simple) use case:


I’m building a card component that includes multiple nested button components.


I’d love to be able to expose to end users of the card component certain of the nested button components’ properties that they’ll need access to (e.g., button state variants, text property, icon swap property) while restricting/locking down other properties that would only serve to break the layout, mess up the intended hierarchy or otherwise break consistency guidelines (e.g., button size and style variants).


+1


Indispensable!!


Coincidentally, I just watched this presentation by Nathan Curtis from Schema 2022 in which, almost as an aside starting at the 14:14 mark, he briefly makes the case for this as a need along with a related/alternative feature idea (“forwarding” property values from a main component to its nested instances):





And maybe in the future (wink-wink, Figma) we can get to the point where we aren’t just exposing nested instances, but exposing properties within exposed nested instances. And being able to maybe forward properties from something bigger to something smaller, so that our consumers of the design system, when they’re working with a bigger unit, aren’t overwhelmed by having to configure and align all of their different knobs they’re trying to tune.



+1

Really really needed!


+1 lets do it


I use 🟢 and 🚫 to mark properties consumers can or cannot touch. It’s obviously a workaround but it helps. Still the feature allowing to show/hide nested properties would be highly appreciated 🙂


I want to +1 this thread one more time to bring this up. These “little big updates” are amazing, but I kinda hoped this feature would be added too. We need this. This one can save so much time and reduce the complexity of an instance. If you see this & didn’t vote for it, please go for it now.


Yes please! +1


+1 we need this for our design system! 😃


This would make our components properties so much cleaner, 100% agree


Really needed in control of massive Design System please do this ASAP guys! @Figma_Moderation @Celine_Figma 🤧 😐 😶


+100000, this is really needed!! 🔥


We need this…


Yes please. So crucial


It’s still needed. Please? Pretty please, with a cherry on top?


Need this as well !


I will piggyback on this and say I have definitely found a need for this within our system. For example, Have a core navigation component created for my team.


Some properties are pre-defined and should be the same across all instances (ex. Menu Item A should always have “Show Right Icon” on because it’s a link). I need the ability to lock or hide, since team members should not be able to override this decision.


However, in the same component, there are properties that my team should have control over, such as changing Menu Item A from “Unselected” to “Selected”


Keeping this open because I need this too on our design system…Hi Figma!


+1, is really needed!


+1, we need this.


Reply