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
@Lindsey_Drennan Oh but 5 months ago we got this message don’t worry :)
jjcm wrote:
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
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.)
+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.