Preserve nested symbol text overrides

There is a long standing issue where if you have a symbol with nested symbols, and you override one of the nested symbols it’s text and whatever other icons get reset to the source symbol.

To combat this I had a plan to override the default text of each nested symbol so that when I switch symbols it wouldn’t reset it. However, when you override the text of the nested symbol to be the exactly the same as the default text - sketch will ignore your override and reset the text anyway.

Here is a video to show what I’m talking about:

Hello!

We already got a internal fix as a feature flag for this unexpected behaviour/“bug”, we need to explore this further, it’s not slated to the next update, but we’re surely addressing this soon.

Thanks!

3 Likes

I am having this same problem with Sketch Version 98.2 (176424)

1 Like

Hi @Camila and @jkilp

I was testing this case and there is a workaround that can help: add an instance of your menu and detach it. Smart Layout settings will be preserved in the detached group and there you’ll be able to swap between the different states of the menu items (hover, active, etc) without the text being reset.

Would this help?

Hi Jorge, I have created the menu component because I have been using it in 150+ different screens across multiple pages.

The old menu on these screens, that were detached, as you mentioned, didn’t keep up with updates made to the main menu component, which caused inconsistencies. And I’ll have to correct 150+ screens manually to have it right every time an update happens.

Hi @Camila thanks for sharing these info about your use case.

When you need to use instances one way to avoid the text being reset is to override the style of the symbol, for example, the background color instead of swapping the whole symbol.

I have a question though: how have you managed this issue so far with all the screens you need to keep in sync?

Thanks in advance!

Most of the files I have received from the previous designer have the unattached instance as a workaround. I try to keep everything in components because that’s how I approach an atomic design library. Because I am working in changes in designs that were created previously, most of the time there is a disconnect between the screens designed by the previous design and my own screens. This becomes a big problem when there’s an “app wide” change, but it’s manageable in a small scale.

I managed it by creating two components for the same menu item and hiding one of them in the instance menu. This creates a very big and messy component, and still creates the problem of having to modify them for each section but I can replicate the instance by using plugins, but if the change can be done in the Item component itself then it’s easier than just completely detaching it. I avoid detaching components as much as possible.

1 Like

Thanks so much for the additional context @Camila! :pray: I’ve sent a follow up email, let me know if you have any questions