Here is a Select input component I am working on. The label is a separated component with different states and content property for the text.
I want the parent component to show the “label content” whereas I don’t want user to be able to change the state of the label.
I think we can have a convention where the “_” or “.” in front of the property can make it “local” to the component and not propagate up to the parent components.
Thanks
Might need a little more context on how you have everything structured but you should be able to specify which nested component props show up on the parent component.
I want to show specific properties from an instance, with this I can only show ALL properties from an instance, or none.
We are looking for this Hide specific properties from the nested instances on variant property
or
Hide component properties - #7 by Matthew_Vella
Any update on this ?
This is a must-have feature for any large-scale design system with multiple designers. We need ways to lock down permutations of nested components to avoid user error.
I think it would be really helpful, if there is a way to hide properties. I need this in a lot of complex components. Right now i have to trust the designer, that they don’t use single nested instances wrong.
I can’t upvote this enough. The current component model forces many hacky workarounds to approach something usable, and at best there’s some other tradeoff or invalid configuration you’ve had to expose.
This is the root of most of these problems. We need to be able to compose larger components from smaller ones, while hiding some of the implementation details of the smaller ones. This include hiding properties, changing the “recommended” instance swaps, or even limiting the instance swaps allowed.
Our team is working on a new design system and it’d make things so much easier if there was a way to hide specific props of nested components depending on where they are used. Otherwise, the props panel can grow unwieldy pretty fast and it would make so much sense to tailor exposed props to the specific use case.
@Figma-Team: Could you share if you’re even considering such a feature? It would really help us to decide basic questions regarding our component structure. Thank you!
We are also building out of design system, and I can concur that this would be super helpful to make the components easier to use and handle when creating mocks.
It could be as simple as a eye toggle so you can choose what to hide and what to show.
I like this idea as well. The workaround for me was breaking variants into separate components to prevent user error when using nested instances.
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).
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.
