allow Hero widgets to have transitions within the same screen

[AnuragVadd]

Use case

If i have a design similar to the gif below -

and I want to avoid using another page, I will be unable to implement it since Hero widget does not seem to have the functionality to work on the same page. I have tried to search for a similar package which would hopefully work as intended as per my case but there does not seem to be a lot of them.

Proposal

Allow Hero widgets to work on the same page without having to navigate to another page.

[mannprerak2]

You could nest another Navigator to achieve this.

[chunhtai]

@Hixie @goderbauer and I had a offline discussion briefly talked through how we should refactor the hero controller.

In short, we should come up with a way to decouple the hero controller and the navigator, and make the hero controller more generic to support beyond the navigator.

One idea is to revert the dependency between navigator and hero controller. Instead of having hero controller listening the navigator, the hero controller should passively waiting for hero widget to register their hero flight details. The details may include from-widget and to-widget, the driving animation... and etc.

The hero widget, on the other hand, listens on a generic hero context that is inserted somewhere above its widget tree. The hero widget register its flight details when certain conditions are met in the generic hero context.

The navigator will be the one that insert the hero context in its widget subtree and change the state of the hero context based on route changes.

In this design we can trigger the hero animation without a navigator by having a custom widget that manually insert the hero context above the hero widget.

Lastly, the hero controller needs an overlay to insert the animation. There are multiple options:

1. hero controller create its own overlay for its subtree
2. hero controller constructor takes in a overlay context (probably won't work in router api)
3. overlay is part of flight details that hero widget provides

[TobiasHeidingsfeld]

This would be a super great feature to have. Any progress or even ETA?

[chunhtai]

There is currently no progress done or an ETA, please thumbs up to bump up the priority

[fzyzcjy]

Hi a season has passed, is there any updates? (there are 40 thumb ups now!)

[chunhtai]

We still have no plan to work on this, but we welcome contributions from the community.

[chunhtai]

It looks like our HeroController has problem to work with Nav 2, It may be the good time to start working on this

[chunhtai]

I would like to know how would one expect the API to look like. Let's say you have a hero in the appbar, and you want it to fly to the center of a scaffold body. Any feedback will be helpful, thanks.

[FMorschel]

I would like to know how would one expect the API to look like. Let's say you have a hero in the appbar, and you want it to fly to the center of a scaffold body. Any feedback will be helpful, thanks.

Hi, I think it would do just the same as the existing features, fly the widget to the next location and transform it if needed. Just place the widget with the tag inside de body and remove it from the appbar, set the state and you're done.

[chunhtai]

@FMorschel That will be a problem since the fromHero may be disposed before the toHero is created. The current strategy requires the fromHero and toHero to coexist at least one frame to create the animation. It is possible we memorize the location/rect of the from hero from previous frame to be used when to hero is created, but i imagine that can create a bunch of corner cases. Also, they can be apart for several frame due to some other animation, and developer may still expect the hero to trigger.

I may need sometime to digest, in the meantime, any other idea is still welcome

[FMorschel]

The current strategy requires the fromHero and toHero to coexist at least one frame

The thing is, how could we detect where to and from in this case?
I see why it wouldn't work, just don't have any more input at the moment.

[chunhtai]

Right now it relies on the route transition, and the form/to hero coexist on the previous route and new route when they are still transition. Since it is a route transition, we know which one is the fromHero and which one is toHero.

Another idea is make this imperative, for example, instead of detecting the from and to position. we can do some thing like

myHero.currentContext.flyTo(<someInput>)

but it may be tricky to determine what the <someInput> should be

[Edorin9]

I'm currently trying to figure out how to apply a "Heroish" animation between images. I have 2 lists that switches back and forth using AnimatedCrossFad. I have an image for each list item.

[MDSADABWASIM]

To achieve this we can use local_hero package
It provides a widget which implicitly launches a hero animation when its position changed within the same route.

[FMorschel]

Another idea is make this imperative, for example, instead of detecting the from and to position. we can do some thing like

myHero.currentContext.flyTo()

but it may be tricky to determine what the should be

@chunhtai
Maybe we could use something like DragTargets and a Draggable? Maybe with some kind of controller similar to a FocusScope to FocusNodes (these being the DragTarget like widgets).
For example, we could use a Draggable like widget as the tagged Hero, and some possible positions on the page, something similar to a FocusScope could exist so we could work with something like nextFocus() method.

[taylanyildiz]

@AnuragVadd , @chunhtai
Hey, I know, too late to answer :)

I have an idea for hero-like animation between two widgets. Use OverlayEntry
need source position and target position for transition animation.

I used on GridView on this project.
source code : https://github.com/taylanyildiz/hero_like_animation

[srihari9n]

Hey @chunhtai is there any update on this proposal ? Any lead would be appreciated. Thanks.

[chunhtai]

related issues
#88578
#74228
#110426

[chunhtai]

We also have internal report
b/273761939

[chunhtai]

WIP dd flutter.dev/go/hero-refactor

[chunhtai]

another use case #32972

Hero animation in AnimatedSwitcher or PageView

[Hixie]

I don't understand why this use case wouldn't use a route. Surely while the user has the zoomed-in image, the back button should unmagnify, rather than quit the entire app?

[flutter-triage-bot]

This issue is assigned to @chunhtai but has had no recent status updates. Please consider unassigning this issue if it is not going to be addressed in the near future. This allows people to have a clearer picture of what work is actually planned. Thanks!

[flutter-triage-bot]

This issue was assigned to @chunhtai but has had no status updates in a long time. To remove any ambiguity about whether the issue is being worked on, the assignee was removed.

[chunhtai]

current status, we are reprioritizing work. This has been deprioritized before, but this may change in the next couple of days. Will give more update later