Library Component Overrides Broken (makes it useless)

[Corey_O_Brien]

Continuing the discussion from Library component instance loses component overrides when variant is changed:

Having the same problem as the original OP. I have a slot component that has a interior component in it. I set the guts of the interior based on the module the page shows up in and that part works great. What doesn’t work is then putting prototyping on the component.

My situation is this. I have a card that is a section summary. The base of the card is the same but the guts of the summary is different per section. I want to let users toggle showing or hiding the details of the card. When they do this, using the instance, the component will revert back to the default state every time it is toggled.

This makes component variants and prototyping states completely useless for this type of component. Please fix, or at least comment on this. I see there were no comments on the original post.

[tank666]

Could you share a link to an example file?

[Corey_O_Brien]

Not easy to do. It is a software design that is proprietary so I would have to create a new library, a new file, then the components, then prototype them. Maybe if I get some time later tonight.

[tank666]

Okay, I understand. I would like to know the structure of your component. Could you show a screenshot of the layers panel showing both collapsed and expanded variants?

[Corey_O_Brien]

Here is the component. The “summary_slots” inner component is the one that reverts back when I expand or collapse the main card.

[tank666]

Thanks for the screenshot. The “Expanded=false” variant has a hidden layer “summary_slots”?

[Corey_O_Brien]

Currently no, but I tested it that way as well and it still reset the “summary_slots” component back to the original slot when I changed the state of the parent.

[tank666]

The absence of a “slot” instance in the collapsed variant is the reason for resetting the override. You need to make sure that the structure of your variants and the layer names are identical.

Solution:

1. Place a “slot” instance in a auto layout frame (let’s call it “content”, for example).
2. Apply the component’s instance swap property to the “slot” instance.
3. Then control the visibility of the “content” frame in your variants.

[Corey_O_Brien]

I tested that and it still didn’t work. Let me see if I can get some time to make it generic and test sharing it so I can show you.

[Corey_O_Brien]

As the previous thread said, I think it is related to it being in a library vs directly in the design.

[Liam_Sheppard]

I have a similar issue, with icon colours being reset on updates.

I’ve tried a bunch of different methods, but the behaviour doesn’t work as expected.

For reference, here is the setup of my component:

Replacing any of the “Shape” layers with a new “Shape” layer and pushing library updates causes all instances to reset their colour back to black. I’d very much argue this behaviour is entirely unexpected and broken.

Replication:
I copied one of my icon components and imported a bunch of different variants into a different file, then changed the colour.

I attempted:

• Adding new “Shape” layer, deleting old “Shape” layer
• Deleting old “Shape” layer, adding new “Shape” layer
• Selecting old “Shape” layer, paste to replace with new “Shape” layer

^ In all these cases, the component structure was the same as when I started — 1 vector layer named “Shape”

After pushing updates, I went to my file and updated components. Boom - All colours have been reset back to black.

This is a pretty core behaviour of libraries and it’s been broken for a few weeks at least.