Master component changes do not update on children if master has subcomponents
1) Create a rectangle with a black fill, convert that rectangle to a component.
2) Use an instance of that new component to create another component (perhaps in addition to a text layer so those two together make up a button)
3) Change the master of that button component to have a red background color
4) The instances of that button component do not reflect the red background, even though they have 0 overrides
Expected: Changes in a master component get reflected in its children
Result: Child components retain the initial state, even though they have no overrides
Thanks for your reply. Apologies if I was unclear – I didn’t mean to say that all your nested components must be master components, but to demonstrate that if you are editing master components, the edits will propagate to the other instances.
So in the original example you posted, you were actually overriding the fill color in a nested instance (not a master component). If instead, you right-clicked on the nested instance and chose ‘Edit Master Component’, your viewport would have panned to the master component, and then any changes you made to the master component would propagate to its instances. It doesn’t matter if the instance is nested in another component or not.
So nested components are fully supported in this new master/instance model, but the important thing to remember is you must edit the master component, either directly in the parent component or by right-clicking on it and choosing ‘Edit Master Component’. Then any changes made to the master component will apply to all instances that have not had the same property overridden. Otherwise, you’re overriding a nested instance.
Hope this clarifies it,
Eniko Rozsnyoi commented
I confirm, its a problem here as well.
I use a (non-master) component nested in a master component. If I override the nested non-master component (e.g.) hide a layer, I would like that all child components of my master will reflect those changes.
Martin Klausen commented
Here a file for clarification which shows the unexpected behaviour
Definitely agree that this is not a great/expected user experience for nested components.
I also would love to see a feature update/improvement with hose this works.
Any updates on this? @Joe/Admin?
This really limits what can be accomplished with Components.
If Component B contains Component A with overrides defined within B's master, instances B should include Component A with the overrides as defined in B - NOT the original version of A.
Let's say I have two screen templates - Component A and Component B. Component A includes the layout and positioning of a whole bunch of images, buttons, text, etc.
Now I need a variant of A which has elements in slightly different positions, or has an element removed. I don't really want to maintain two completely different components. That would be a lot of wasted time and effort creating nearly the same layout twice, but with minute differences. I would have to manually position all of the elements again from scratch. An easier way would be to create Component B, whose master contains an *instance* of A. I edit that instance of A as necessary. Basically what you're doing is creating pre-set overrides of A by making them into their own components, but they are all just overridden instances of A.
This works fine up to this point. In fact even if you grab master component B and paste instances of it into other documents, it will work fine. The problem is when you need to change B. If you edit any overrides to the instance of Component A that was placed inside master Component B, they will not propagate to the other linked instances of Component B. And, if you go to the instances of Component B and hit Reset to Master, you will find that the overrides to A reset to the master Component A appearance - NOT what you had overridden them to be within master Component B.
Is any more info required for this bug?
I have the same issue. I create a master component. This last one is used in another file via the linked component functionality. I modify my master component and some artifacts stay in the nested component when I use it in the other file.
For the moment, I have a lot of regrets to "migrate "from Sketch to Adobe XD. The management of the components is really a nightmare!!
A good example that showcases this bug or wrong behaviour is the Design System UI Kit itself:
Right now there are several button components, but they dont share a common master.
If I wanted to have a different border radius I'd have to change every single button component, as I cant set a "button.default" as the master and just change its color because XD wont save my overrides.
I'd expect to create my components to save those overrides, as they make my new component.
In order to allow the creation of true design systems we need the possibility to create atomic designs with various components being part of other components, propagating changes.
@Nina just want to point out that this issue is the same thing:
Any word on whether we can expect a fix for this would be great, because without a fix on the horizon we will need to structure our component libraries sub-optimally as a workaround.
This is incredibly annoying. It makes components with text virtually useless.
If I create a component using a couple of character styles and icons (eg, a carousel with a heading & sub heading) - I want to use this instance across pages of a website. But the text would change per page.
It's complicated by the fact i have to split out my desktop/tablet/mobile files to upload for review. (I create all in one master file, then create 3 separate files to upload & show a client) - When I paste my pages into these new documents, text in each component is reverted to the master one.
However, within some buttons I've created this hasn't happened. It's really weird.
@Nina I was going to provide more info but it looks like @Benny has already attached a video below showing the exact issue. The behaviour I would expect is that instances of a component respect all of that master component's properties, including any sub-components that may have overrides.
Benny Liebold commented
I attached a video of the issue. The problem is that instances of components within nested components are always masters instead of instances.
Thanks for your reply. Creating a larger design system however requires components to be nested and being used as a base for other components just with overrides).
Think of a common button_bg component that defines the basic shape (border radius) of buttons. I would use that common component in all other button components, propagating any change of e.g. the border radius to the other components. I'd use that button base component with color overrides in all the buttons.
Requiring all components to only have master components somewhat interferes with that approach.
@Armando: Exactly, I believe all changes to subcomponents simply get ignored inside components and revert to their original layout.
Benny Liebold commented
This is exactly how I started using the feature.
This is either a bug or sorely needed feature with the new component update.
Make component A.
Make an instance of component A and change something, like the background colour. Make that instance into its own component, call it B.
Expected behaviour is that if I make new instance copies of B, say by copy and pasting it into a new doc, it will look like B including its overrides. Actual result is that instances of B will look identical to A because the overrides of the subcomponent A are not being carried over.
It seems like all subcomponents of a component are reset to default master appearance for each instance.
Armando Scuro commented
What I noticed from testing, is that if the component has another component or even a group inside of it, changing the layout inside the nested group/component doesn't propagate changes of master component to its instances.
basically only changes done to content inside a component propagate, not changes done inside a nested group/component
hope this helps, and hope this is what Jan was discussing