LAUNCHED: State management for prototypes

@Guillaume_BRACHON which frames - the topmost level “artboard” frames? or a specific layer??

I see now! the top most level frames

Yes, the top level frame, the one that corresponds to the web page / app screen.

it’s all i needed, Thanks!! :heart:

1 Like

Did you find any solution to this? I’m having the same issue with my input select dropdown. The options don’t render the hover state but instead ruins the click event.

@Bryan12 I think I found a solution, but it only works sometimes.

Inside of my nested component , I applied the Instance Swap Property for my text and icon values.

this allowed me to create different component variants and keep the state on interactions.

I hope this helps!

This is a great addition! Thank you for following up on this :heart:

Hi, is there an option to persist component state between artboards? E.g. having a toggle on frame A and frame B that is inactive by default. After toggling state to active on frame A, navigating to frame B will reset the toggle to inactive.

Is it possible to persist state between frame changes?

Btw super happy about interactive components! What a great and powerful feature! Thanks for the beta invite!

12 Likes

Hey Dan! Right now we don’t support state preservation for interactive components, but it’s something we’re thinking about and would love to support in the future.

Glad you’re enjoying the feature, and keep the feedback coming!

3 Likes

FYI just changed the category on this one from Questions to Feedback so we can make sure to keep track of it on the product side.

2 Likes

Hi Kelsey, thanks for the fast reply! Would be awesome to get this feature down the road.

Hi, we need this so badly too. Btw, enjoying everything in Interactive Components. Thanks so much :smile::raised_hands:t2:

3 Likes

(Maybe)Think this could be a simple boolean on the page/frame level to reset/lock states to whatever it is set to when navigating. So, if I had a checkbox, I could just toggle on lock state for that variant and when navigating back it would set/keep whatever the state was in whatever position in the flow.

1 Like

Howdy! I think this is the right feedback channel for this concept. Please direct me to the correct one if I am wrong. This feature is pretty critical in my eyes for instances where we want the interaction to happen each time the trigger happens. I’m trying to use this for “on load” type events with a delay and I’m not sure how to trigger it each time a prototype page loads. For example. I have it fade in. The reason I don’t use a typical delay is that I want the animation sequences to overlap and this is the only way I can figure out how to do that.

1 Like

I have an prototype with a volume slider in every artboard. It has its own states and I can interact with it perfectly, but when I change artboards, it resets to the initial state of the volume slider and when I change back it goes to the value you I changed it too. It is really annoying.

I am designing an app for an automotive application. In it have applets on the screen that really want to keep their own state independent of the top level state. Currently that is not possible.

But I also want to be able to change the state of a component and have that event bubble up to the main artboard so that I can use that event to drive a change in the main artboard. ex: a component changes state and gets bigger and that triggers other components to change their state to get smaller. I can do that by creating every variation at the parent level, just annoying.

Actually, I do not understand why an interaction on a component where the interaction is define inside the component doesn’t affect every instance of the component. It is one thing if I edit the variant of the instance, but If I drop an instance on an artboard, it should be honoring the current variant of the component… I guess that is the difference between dropping an instance of a component and dropping an instance of a variant of a component. I prefer to think of it as dropping an instance of the component.

Technically, if I have a component instance on several artboards and a subcomponent of that component instance has variants, I can change the subcomponent variant in the master of the subcomponent and it will update everywhere it is instanced is used unless overridden, so that logic exists in design time. It is just not maintained at runtime. At runtime, I can change the variant state of the deep subcomponent via an interaction and it is not the same as changing that variant state directly in the subcomponent at design time… I would think that design time and runtime should act the same way. Changes in the deep subcomponent stick in all instances unless overridden at a higher level.

3 Likes

Would love to see this implemented, makes prototypes much more viable.

1 Like

+1 for this feature

2 Likes

I really need this for a choose favorite function im designing:)

1 Like

Workaround:
State stays persistent even in multiple nested interactive component. You can go very far with this approach.

Only reason I would need frame to frame persistence is to reflect some kind of logic or content change.