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.
+1
I think I understand the problem why they still don’t make it now:
Because they are nested instance, they can always be swapped. So if Figma had the ability to deselect unwanted nested properties from the original parent instance, then what would happen to the swapped nested instance. Would they also be configured like the original, or have full set of its properties?
Or if there were a feature to lock the instance from being swapped, this would make more sense.
++++
+1 We really need this one
I can’t believe this thread is so long with no resolution or roadmap to enable this
Hey all, PM responsible for Component Props. Just wanted to say totally hear the desires and needs for this feature, and it’s something we intend to build at some point. Right now other DS-related features are ahead in priority for us, but part of those priorities do include updates to component props. This is not a forgotten part of the product - were still doing active development here.
The priority is not one of the most active thread on the forum, that should be a basic feature, no, don’t worry. It’s probably another shiny thing they can brag about on social media and during keynotes so they can say they have more features than other products.
Just adding on to continue the traction
+1 from my DS team, it would be super useful to have this
+1
Essential feature in my opinion, please follow up, figma Team 🙏🏻.
Huge +1 on this. As the design system owner, I need to be able to allow designers to change certain properties in a nested component while preventing them from changing other properties as easily.
I have many situations where this is needed, but one example is: allowing people to change the value of a text property, without having access to all of the other properties of the nested component (like the size, color, etc.)
This would be awsome
+1 for this:
I have many situations where this is needed, but one example is: allowing people to change the value of a text property, without having access to all of the other properties of the nested component (like the size, color, etc.)
Still waiting… Would be a very welcome feature
+1 for this - many situations where this is needed to help restrict options
+1 .. still waiting for this feature!
+1 as well, this needs to be on the roadmap!
+1
new to the whole workflow but after starting to set up systems I ran into this problem very quickly.
Having a concept of “private” and “public” properties could help, similar to the way using a dot or underscore at the start of component names hides the component from publishing. Only “public” ones would appear to consumers of the library.
At the moment I’m having to sacrifice some of the usefulness of my unpublished nested components by reducing properties in order to prevent too many from appearing.
This is a highly wanted feature! The components we make in our design system gets way to complex for the users of design system to understand when all of the nested props (that they not should touch) need to be displayed – when f.ex. only one of them is needed to be exposed in the main component. Hope ypu will prioritize to fix this soon! Waiting for this for years should not be necessary.
+1 for this also. Maybe prefixing the prop with _ or .
+1 for my team too!
This is a big bugbare of mine. It’s severely holding up how we make components within our design system.
We have core components such as Cards that house content with replaceable body content. This suggested feature is desirable for instances where we want the content inside to be exposed as editable children, but we don’t want the card itself to have its variants changed.
+1 What can I say – essential for a complex design system (to make it less complex for its users).
+1, why does this functionality not exist yet?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.