Skip to content
This repository was archived by the owner on Jun 13, 2024. It is now read-only.

Conversation

shihaohong
Copy link

@shihaohong shihaohong commented Jan 27, 2021

Related to flutter/flutter#62916.

Made the following demos state restorable:

  1. Material Dialogs
  2. Cupertino Dialogs (except ActionSheets/Modals, those will come when the framework changes ([State Restoration] CupertinoModalPopupRoute flutter#74805) have landed)
  3. CupertinoTabScaffold/TabView
  4. CupertinoTextFields

'alert_with_title_press_demo_dialog_route');
}

void setSelectedValue(String value) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make private?

Suggested change
void setSelectedValue(String value) {
void _setSelectedValue(String value) {

}

void setSelectedValue(String value) {
setState(() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the old code, this only happened when value != null - should we keep that behavior?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, sorry about that. I think I confused myself moving between NNBD and non-NNBD codebases, since the gallery is still pre-NNBD

void _showDemoDialog({BuildContext context, Widget child}) {
showCupertinoDialog<String>(
static Route<String> _alertDemoDialog(
BuildContext context, Object arguments) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit (although I am not super familiar with the code formatting style guide here): I'd add a trailing comma behind arguments and format this in multiple lines.

onPressed: () {
Navigator.of(
context,
rootNavigator: true,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why rootNavigator: true here and elsewhere? Isn't the dialog just pushed into the closest enclosing dialog?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, you're right. Again, I just copied over the behavior that was in the existing code, but it's not necessary so I removed it

Comment on lines 101 to 107
final themes = InheritedTheme.capture(
from: context,
to: Navigator.of(
context,
rootNavigator: true,
).context,
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to capture these themes? My understanding is that is is capturing the themes between the Navigator that will own the route and the root Navigator. However, everything above the Navigator that will own the route should already be visible to the route, so there shouldn't be a need to capture?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question for the instances below.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was just copying the default behavior without attempting to modify anything, but you're right, it's unnecessary. Removed it!

Comment on lines 113 to 114
child: Theme(
data: Theme.of(context),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this? Isn't this just wrapping everything in the same ThemeData that children could access via Theme.of even if it wasn't re-wrapped like this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same question for the instances below.

@shihaohong
Copy link
Author

Addressed the code review and added action sheet state restoration, since that has made it into the flutter/flutter master branch. PTAL

Copy link
Member

@goderbauer goderbauer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@shihaohong
Copy link
Author

shihaohong commented Jan 28, 2021

Odd, the web-benchmark tests are failing on the windows check for reasons unrelated to the PR. I'll look into it more later, but I'm not really sure what's going on at first glance (it might be an NNBD, but not sure why only Windows would be affected?).

@shihaohong
Copy link
Author

The web benchmark tests have been fixed with flutter/packages#281 and is unrelated to this change.

@shihaohong shihaohong changed the title More State Restoration [State Restoration] Material Dialogs, Cupertino Dialogs, CupertinoTabScaffold/TabView, CupertinoTextFields Feb 22, 2021
@shihaohong
Copy link
Author

The golden tests are failing, regardless of whether they have been updated or not. In any case, these changes should not have resulted in the golden failures seen since the state restoration changes do not contain any UI changes.

@shihaohong
Copy link
Author

Merging with the failed run goldens, since that doesn't seem related to the changes made in this PR

@shihaohong shihaohong merged commit 752ca54 into flutter:master Feb 23, 2021
@shihaohong shihaohong deleted the more-state-restoration branch February 23, 2021 00:10
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants