Allow component instance overrides to be inherited by all states
Currently (XD 22.214.171.124), if I drop an instance of a component and then adjust part of it (text in a button, size of the instance, etc.), that override is only applied to the selected state of the instance. So, if I have a button with many states (normal, hover, disabled, active, default action, etc.) I have to manually apply that override to each state of the instance. This is extremely tedious and error prone.
Please provide the ability to have an override of an instance be inherited by all states in that component instance.
As a new user, I found the lack of this feature to be immensely frustrating and one of several workflow issues with components and assets that really hurts XD in terms of building a design system. There is an incredible opportunity with the DSP format and VSCode plugin I am hoping to use here but to get there I find myself forced to do a huge amount of rework to make what should be simple variations of main components to add to the asset library.
adam sontag commented
I'm in the middle of getting started with XD and this is just a brutal lack-of-feature to stumble across. Trying to use existing design systems for prototyping and figured this would be a slam dunk and is instead making me consider other options.
Florian Meyer commented
Very poor that this features is not implemented after nearly two years. How many developers work on such important features for XD? Zero or even one?
I'm new to XD, i'm a figma user but I wanted to give it a try. This HUGE issue is definitely a deal breaker for me! The request has been made for almost 2 years !
Arthus Ribeiro commented
I´ve been using XD for just a couple of months, saw people asking for this feature during 3 years now (2018), with no solution, and I am already so frustrated about this.
A lame ass workaround in some cases could be to make a separate component of only a button-bg i.e. and give this his own 'hover'-effect.
Than group this with the variables (text) and create a new component who contains both.
Nesting components is the closest we can get.
But I'm very dissapointed that - even after 2 years - Adobe didn't took us serious on this point..
Sketch is far ahead on this point...
Please fix this very basic thing. I'm currently trying to make design libraries easier for the other designers, and this makes it harder
Vote up for this! This is absolutely counterintuitive. If I write a button in pure HTML, when I change the text in a button, I am expecting the hover state to reflect the change as well because the HTML takes care of the content, and the CSS takes care of the style. The current workflow doesn't reflect the front-end logic. I also hate the current status of switching between states when modifying the styles. It's so confusing and prone to mistakes. So many times I've done my modification and found I am in the wrong state. That's super frustrating. Why can't you guys come up with a panel that summarizes the differences into several properties that we can play around with? Like what Figma has.
I don't even use hover states for this exact reason. Way too much of a pain!!!
Mustafa Miraç Erkesim commented
Hi Katie! Did you find any solution for 'Fix Position When Scrolling for Individual Objects Inside of Group
' İf you find can write here. İ need also this function. Have a nice day.
Also you can reach there: firstname.lastname@example.org
Bert de Weerd commented
Huge timesaver when working with component states to have this fixed. It's currently taking way too much time to change all states for simply having the icon and/or text label of a button to be consistent over all states.
Even if you don't want this behaviour, simply change the text layer name in that state.
Seriously, I waste so much time changing a button name across all states. I am about to loose my mind!!!!
This is the most aggravating thing about XD for me. Please, please fix this, fast.
For me this is actually the biggest issue about Xd and it makes me really consider about switching to Figma (plus the fact that we cannot organise components per categories or create pages within a single file, which makes creating and sharing complex design systems really difficult).
You guys have done such a good work on components so far, but this lack is actually a deal breaker for larger projects since we have to do it all again manually every time we want to create a new instance (modify texts, icons, for all states including hover, dark mode...), losing the point of defining components in the first place. On this point Figma is way ahead and enables to save a lot of time when it comes to the UI design process.
Mohammad Harb commented
this feature should have a button to toggle it on/off. It's essential and beneficial, but in some cases you mean to edit only one state of the component.
Angela Fioretti commented
How is this not the highest priority? This should be treated like styles not manual edits, at the very least address it for text driven items like BUTTONS and NAVIGATION (things that are on EVERY design). At the very least make it so you can copy the style of ONE change and apply it to the others. This is encouraging me to buy figma instead - the wasted billable time doing this tedious task is not worth it.
Stop reviewing now, develop it !!!
Marc Geiser commented
That this doesn't work costs me a lot of work every day, especially on projects with a lot of repetitive but slightly different elements. This needs to be fixed urgently. Currently, I am looking for alternative solutions for this reason, among others.
Stuart McCoy commented
Not having this feature implemented yet is embarrassing. It's been nearly two years since this was requested and quite frankly its lack makes this app unusable. This should have been the default behavior from the very beginning.
This is the single most painful hole in the XD experience. I have 5 states on all my buttons and the app I'm working at the moment has a LOT of buttons. In many cases, those buttons also have a leading icon.
Multiply this by five:
1. Change the text
2. Swap the icon component
3. Recolor the icon component (because it forgets the color override)
4. Resize the icon component (because it forgets the size override)
5. Switch to the next state
Component states are cool, but you pretty much hate them once you have a large app prototype up and running and you keep finding states you overlooked in your late night cram session.