With auto layout, everything worked perfectly. Without auto layout, if the instances of the base component are used directly, it works perfectly as well. However, if I create an instance of a base component and then convert it to a component, setting the base component as a nested instance, the different sizes of the base component do not work. Changing the constraints of the base component’s variants somewhat resolves the issue, but the container does not change, leading to unexpected behavior.
So, my question is, why does changing the size of instances in the base component work when the instance is used directly (I mean just copy or drag an instance in base component and changing its properties), but not when it’s used as a nested instance?
More info:
Base component consist of two variants of rectangle (large and small).
In nested instances (for changing color) without auto layout (right section of the screenshot), applying large size to the rectangle (green) wont work.
Thanks for the post! When we perform variant/instance swaps of a regular nested instance, we will maintain the size of the original nested instance, even if the swapped in instance is a different size. This is the extent of what we can disclose for now.
Apologies for not being able to delve into more detail, but I hope this provides some clarity.
Does this mean that it is being worked on? I’m also having this same issue. I have a flexible card component (frame with title, blurb and link) and an image component with different size variants. I want to make a Card with Image component using these two child components. When I make this element using an instance of both of these components, it works beautifully. When I make a component using the two, the image size does not respond when I swap out size variants.
Our engineers have informed that unfortunately this is expected behavior and an existing feature limitation. When we perform variant/instance swaps of a regular nested instance, we will maintain the size of the original nested instance, even if the swapped in instance is a different size. However, as you noted, the workaround here is to add auto-layout to the nested instance, and then swapping between the variants will resize as expected.
Thanks so much for getting back to me so quickly. I’m new to Figma so forgive me if I’m not doing this properly, but the work around you described doesn’t seem to work. Here’s a video of what I’m doing -
Taking an image component w/ a few variants
Grouping it with a card component with auto layout
Changing the image variant to see that it adjusts
Converting the group to a new component
Creating an instance of the new component, changing the nested image variant, and seeing that it doesn’t adjust.
Am I doing this wrong or is this the expected behavior you mentioned?
Thank you for sharing the video. Indeed, that’s what I was referring to. Regrettably, this is the expected behavior. However, if you apply auto layout to each variant, it should function appropriately, I believe. Alternatively, you might need to create it without using swap instances, although I understand that may not be the most convenient solution for you.
I can confirm that creating an auto-layout of your child instances solves this problem but it needs to be clearly understood that this is a problem with an unnecessary workaround and not what I would regard as ‘expected behaviour’. You should be able to nest component instances and have the other objects move and the parent container grow accordingly, this just makes sense.
Just spent several hours struggling with this problem before finding this ‘workaround’.
And yet, the workaround is incompatible with Boolean properties that rely on constraints.
Specifically speaking, my Boolean property to toggle focus rings around buttons has broken, because focus rings can’t be manually positioned with auto-layout.
So I created 2X variants: 1 set to show the focus rings, and 1 set to hide them. And, it still didn’t work. I then had to split out every pair of variants - with/without the focus ring - into separate components.
This is very unintuitive and inefficient.
It should still be fixed per OP’s original comments.
