Allow components event to change states of other components
New states feature is excellent but restricted for self components interaction. In many cases, especially in web and desktop apps, there are cases where a component event should affect another element on screen.
It would be a super powerful option to allow a component event to change states of another component.
Currently if i use component A inside component B, i can't use A to change state of B, even though A is part of B.
This is really necessary. I have to apply so many workarounds to my Prototype right now...I just designed a toggle switch, but the only visualisation I can add is toggling the switch itself on and off. This is not a real life use, switches are used to have an effect on something else other than themselves...
This would make many common interactions super easy. In my example I have four buttons. Each button has a set of states. I would like the blue button to change state if I click any of the other buttons.
I also would love to have this feature, it is an important aspect to have when making interactive prototypes
Jerimy Brown commented
I need this so badly, I voted on this a long time ago, and just came back to see how it's progressing... I just wrote another request that, if combined with this one, would make XD a real powerhouse of micro interaction possibilities.
The new request I just wrote asks for definable hit areas for states... Right now if you have a state and add something bigger to it on rollover(for example), rolling off the original trigger doesn't return to default state, because XD assumes the hit area of the entire new state, weather that was your intention or not LOL.
Matt Penner commented
This would be a huge feature for prototyping several user interaction scenarios. Currently we are trying to prototype a design where the user has a "focused" view. They can check a few different info cards on their screen (which contains many) , click the Focus View button and all but the checked cards would disappear. I would like to hide the unchecked cards based on whether they are checked or not, and whether the Focused View button has been clicked.
I can simulate this by creating multiple art boards where I manually check the cards and then transition to an art board where they are hidden, but this totally loses the user interaction/testing since they cannot check cards of their choice.
In this scenario the parenting strategy doesn't help as I need to go the other direction (change a child component's state based on a parent or sibling component).
Josué Sotelo commented
I need this urgently. So basic, It will reduce my art-boards count in half!
Mike Britton commented
This would allow us to create plugins to output designs for angular and react component architectures.
Seconded! I have the same issue that some states of component A would need to affect a state of component B. So far I have not found a way to resolve this, which is a very common behavior for drop-downs, icons and what not on web- and desktop apps.
Would be brilliant to have this feature.
I have 3 components, two of them have hover's state, the third's state depend of the state of the others components.
Came here after trying to do exactly that. Component feature is very important, and glad they're working on it. But it has to be more robust - looking forward to updates on this.
If you have a parent component that contains a child component, you can try adding a group around the child component. Once you do that, then you should be able to target the parent component's states. In more detail:
1. Drag an instance of your combined parent-nested-child component onto the canvas.
2. Go to Layers panel and drill down to select the child component.
3. Right-click the child component in Layers panel and select Group. You should now have a group that only contains the child component.
4. In Layers panel, select the group you just created, then go to Prototype mode and go to Property Inspector.
5. Click the Plus button next to Interaction and select Tap or Hover.
6. The Destination field should now let you see the states for the parent component.
Hope this helps,
I love the new states support. Great feature and very useful. Thanks for providing that feature. But I would like to see this feature in near future.
As a workaround I create in component B an opaque rectangle (or other filled path) above the child component A as a reactive area. So instead of creation an interaction on component A I create the interaction on this rectangle which allows me to link to another state of component B. Would like to skip this workaround because it works only for simple component structure.
Jerimy Brown commented
OMG... I can't believe we are having to ask for this. I was so excited about component states because I assumed it would launch with this ability. This was the first thing I attempted with this feature. I also can't believe I am only the 40th vote on this request, but at least I didn't have to write the request, which I was on my way here to do LOL.
This would make it so XD could destroy the competition on prototyping and it's what I assumed we were getting, when they advertised it as component states, instead of button states... What we got was button states, not component states, what a let down.
Add an interaction destination type called a "signal." Select "New Signal" from the interaction destination dropdown and name your signal something like "Uncheck All." Let's say you set this interaction's trigger to be to "Tap" a button.
Then, add another interaction on a separate object and you'll find "Uncheck All" as an option in the Trigger dropdown for the new interaction. Let's say you did this for all your checkbox elements (component instances) on the screen and set their destinations to be the "Unchecked" state.
Now you can have one interaction controlling several elements on the screen!
Yes please Adobe, this feature with a lot of potential! it would save a lot of time of prototyping also it avoid copying artboards all the time. We are in 2019 and I dont see the point of keeping the features too basic, (invision). So I really believe you guys can do this!
Roland Weigelt commented
I just have revisited Adobe XD after waiting for the hover feature for months. Now that component states are implemented, I'm trying to prototype a two-level menu - and I'm stuck again. When I hover over an item on the first level, I want to show the menu items of the second level. I manage to highlight the menu item on the first level (easy), but cannot switch to the corresponding second level menu items.
Joseph Silva commented
Absolutely, completely agree!! This ability would make XD super powerful! I love the new states in XD, but I was disappointed that I could not use component A to change the state of component B. I have faith in the XD team that we will get there though! :-)
Alex H commented
yes!!! 1000x yes!!
Harun Alikadić commented
This would be interesting. I vote it. But I do not find it as important as fixing and improving existing features, like the new component states and multiple interactions.
Niklas Drugge commented
Yes absolutely! The new component states are just what was needed for XD, but without this functionality they offer very limited benefits.
I was also trying to achieve something very similar an bumped into this problem. I was hoping to do a list element with a checkbox inside it - and by clicking the checkbox it would change the list element to "selected" state. Obviously I would like to keep the checkbox as a component to use elsewhere in the design as well.
However, since the checkbox is a component, it cannot control the parent elements state - thus making it impossible to change the state of its parent, the list element.
Non-component items CAN control the parent's state, so I would think this would not be that big of a deal to fix. So for example if I make the checkbox not a component, it would work just as intended.
One workaround would be to place an invisible box on top of the checkbox component, that would then control the parent's state, but that's such a dirty way to fix it, that I would prefer not to use it.
TL;DR Nested component interaction destination cannot be set to change parent state - this is a problem!