hiding original hero after hero transition by chunhtai · Pull Request #37341 · flutter/flutter

chunhtai · 2019-07-31T21:42:14Z

Description

If you transition for route 1 to route2, the hero in route1 is hidden during the transition and reappear after transition end. This is generally ok when route2 is not transparent, but looks weird when it is transparent.

after this pr it will hide the original hero

Related Issues

#10667

Tests

I added the following tests:

"Heroes animate should hide original hero"

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]). This will ensure a smooth and quick review process.

I read the Contributor Guide and followed the process outlined there for submitting PRs.
I signed the CLA.
I read and followed the Flutter Style Guide, including Features we expect every widget to implement.
I updated/added relevant documentation (doc comments with ///).
All existing and new tests are passing.
The analyzer (flutter analyze --flutter-repo) does not report any problems on my PR.
I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require Flutter developers to manually update their apps to accommodate your change?

Yes, this is a breaking change (Please read Handling breaking changes). Replace this with a link to the e-mail where you asked for input on this proposed change.
No, this is not a breaking change.

chunhtai · 2019-07-31T21:53:30Z

cc @Piinks

Piinks · 2019-08-01T22:03:40Z

packages/flutter/lib/src/widgets/heroes.dart

Why change the name here? 'placeheld' seems a bit more ambiguous to understanding that the hero is currently flying.

This pr make it so after hero transition finishes, the hero widget in the original route will still be hidden. The placeheld (or isHeroInFlight previously) is controlling whether to hide the hero. After this change, we want to hide hero even if it is not in flight. I feel the name become confusing, and that is why i renamed it. I am open to any name suggestion tho

Maybe a better name would be: showPlaceholder?

Piinks · 2019-08-01T22:04:13Z

packages/flutter/lib/src/widgets/heroes.dart

Can you elaborate further about what this means?

one of the hero should be hidden after the flight, when AnimationStatus.completed toHero will be the one on top, if AnimationStatus.dismissed, it means it starts transition but got canceled, so the fromHero will be the one on top

I will update the comment

goderbauer

I am not sure if anybody depends on those heroes becoming visible again, but for those people, this will be a nasty breaking change. Nasty, because their app will just compile fine and run without exceptions. It'll be hard for them to notice that something is broken. Again, I can't think of any reason for anybody to depend on the fact that the heroes in the route below become visible again, but if we want to do this as a breaking change, we should collect feedback by sending out a breaking change proposal and giving people some time to respond. The breaking change should also be clearly stated in the PR description.

We could also make this a non-breaking change by just having it as a config option on the hero and defaulting it to the current behavior.

goderbauer · 2019-08-02T08:58:58Z

packages/flutter/lib/src/widgets/heroes.dart

Not sure what this comment means?

goderbauer · 2019-08-02T09:08:03Z

packages/flutter/lib/src/widgets/heroes.dart

Add documentation what placeheld means?

Maybe the parameter should be named: keepPlaceholder.

goderbauer · 2019-08-02T09:13:32Z

packages/flutter/lib/src/widgets/heroes.dart

Can this get a more descriptive name? Maybe "ensurePlaceholderIsHidden"?

goderbauer · 2019-08-02T09:14:05Z

packages/flutter/lib/src/widgets/heroes.dart

Maybe a better name would be: showPlaceholder?

goderbauer · 2019-08-02T09:17:42Z

packages/flutter/lib/src/widgets/heroes.dart

Do you have tests for both of these cases?

goderbauer · 2019-08-02T09:18:55Z

packages/flutter/lib/src/widgets/heroes.dart

hide? fromHero is already hidden and we just keep it hidden, no?

goderbauer · 2019-08-02T09:20:19Z

packages/flutter/lib/src/widgets/heroes.dart

goderbauer · 2019-08-02T09:20:39Z

packages/flutter/lib/src/widgets/heroes.dart

Do you have a test for this case?

Also: why's the from hero placeheld?

I don't think this will matter because the old heros are disposed, and it will not be testable because the elements are gone. I modify this just to be extra safe

If it doesn't matter, I'd remove the comment. The comment makes it sound like that this is super-important.

goderbauer · 2019-08-02T09:22:27Z

packages/flutter/lib/src/widgets/heroes.dart

Tests for this code path?

Again, why do we hide them in this case?

chunhtai · 2019-08-02T16:31:51Z

I am not sure if anybody depends on those heroes becoming visible again, but for those people, this will be a nasty breaking change. Nasty, because their app will just compile fine and run without exceptions. It'll be hard for them to notice that something is broken. Again, I can't think of any reason for anybody to depend on the fact that the heroes in the route below become visible again, but if we want to do this as a breaking change, we should collect feedback by sending out a breaking change proposal and giving people some time to respond. The breaking change should also be clearly stated in the PR description.

We could also make this a non-breaking change by just having it as a config option on the hero and defaulting it to the current behavior.

I am struggle on whether to keep the original behavior. I think if we want to provide options, they will be either the fromHero is always displayed or the always hidden. The current behavior is just weird and ugly.

goderbauer · 2019-08-05T17:46:11Z

packages/flutter/lib/src/widgets/heroes.dart

Suggested change

// The 'keepPlaceholder' flag dictates if the hero should keep the placeholder after

// When `keepPlaceholder` is true, the placeholder will continue to be shown after the flight ends.

goderbauer · 2019-08-05T17:47:21Z

packages/flutter/lib/src/widgets/heroes.dart

If it doesn't matter, I'd remove the comment. The comment makes it sound like that this is super-important.

goderbauer · 2019-08-05T17:49:31Z

I am struggle on whether to keep the original behavior.

You can collect feedback for this by sending out a proposal for this breaking change and we can add options if people depend on this.

goderbauer

LGTM

goderbauer · 2019-08-07T22:28:25Z

packages/flutter/lib/src/widgets/heroes.dart

This should probably be guarded by if (mounted) and the if mounted should be removed from endFlight?

liuyingshan · 2019-10-08T09:05:19Z

I am not sure if anybody depends on those heroes becoming visible again, but for those people, this will be a nasty breaking change. Nasty, because their app will just compile fine and run without exceptions. It'll be hard for them to notice that something is broken. Again, I can't think of any reason for anybody to depend on the fact that the heroes in the route below become visible again, but if we want to do this as a breaking change, we should collect feedback by sending out a breaking change proposal and giving people some time to respond. The breaking change should also be clearly stated in the PR description.
We could also make this a non-breaking change by just having it as a config option on the hero and defaulting it to the current behavior.

I am struggle on whether to keep the original behavior. I think if we want to provide options, they will be either the fromHero is always displayed or the always hidden. The current behavior is just weird and ugly.

Is there any option or workaround to make the original hero always visible?

chunhtai · 2019-10-08T16:20:50Z

@liuyingshan
No There is currently not available. If you think that is something we should support, please file a feature request.

liuyingshan · 2019-10-09T04:03:43Z

The placeholderBuilder of Hero may be a workaround for now.
The doc of hero animations is obsolete, since the original hero is hidden after transition.

fluttergithubbot added the framework flutter/packages/flutter repository. See also f: labels. label Jul 31, 2019

googlebot added the cla: yes label Jul 31, 2019

chunhtai requested a review from goderbauer July 31, 2019 21:52

Piinks reviewed Aug 1, 2019

View reviewed changes

goderbauer reviewed Aug 2, 2019

View reviewed changes

chunhtai force-pushed the issues/10667 branch from 7b9c6a2 to 6a04a14 Compare August 2, 2019 20:11

goderbauer reviewed Aug 5, 2019

View reviewed changes

chunhtai force-pushed the issues/10667 branch 2 times, most recently from 25d50d8 to 626a6b3 Compare August 6, 2019 21:06

Piinks added a: animation Animation APIs c: API break Backwards-incompatible API changes c: new feature Nothing broken; request for a new capability labels Aug 6, 2019

goderbauer approved these changes Aug 7, 2019

View reviewed changes

hiding original hero after hero transition

2c1f00e

chunhtai force-pushed the issues/10667 branch from 626a6b3 to 2c1f00e Compare August 8, 2019 20:18

chunhtai merged commit 35532e0 into flutter:master Aug 9, 2019

goderbauer mentioned this pull request Sep 11, 2019

Visibility not restored for Hero after pop #40239

Closed

dshukertjr mentioned this pull request Sep 16, 2019

[BUG]Gallery Example thumbnail disappear when switch PhotoViewGallery pop back bluefireteam/photo_view#178

Closed

liuyingshan mentioned this pull request Oct 9, 2019

Add visibility options on the hero transition #42300

Closed

github-actions bot locked as resolved and limited conversation to collaborators Aug 3, 2021

	// The 'keepPlaceholder' flag dictates if the hero should keep the placeholder after
	// When `keepPlaceholder` is true, the placeholder will continue to be shown after the flight ends.

Conversation

chunhtai commented Jul 31, 2019

Description

Related Issues

Tests

Checklist

Breaking Change

Uh oh!

chunhtai commented Jul 31, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

goderbauer left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

chunhtai commented Aug 2, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

goderbauer commented Aug 5, 2019

Uh oh!

goderbauer left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

liuyingshan commented Oct 8, 2019

Uh oh!

chunhtai commented Oct 8, 2019

Uh oh!

liuyingshan commented Oct 9, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants