Skip to content

Auto populate nav bar title and previous from page route - #19637

Merged
xster merged 11 commits into
flutter:masterfrom
xster:nav-bar-title-2
Aug 24, 2018
Merged

xster merged 11 commits into
flutter:masterfrom
xster:nav-bar-title-2

Conversation

@xster

@xster xster commented Jul 21, 2018 •

Copy link
Copy Markdown
Member

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Is something like this ok for now until your new API or do you prefer changing didPush's signature (breaking API) or add something new?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

yeah it's fine

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I couldn't quite tell from your PR. Is the convenience home: argument on MaterialApp etc going away and everything's going to be specified via Page or wtv we're going to end up calling it or is there still one exception dead-simple API for providing a home widget (to associate a default title with)?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

all the major stuff (including home) will be backwards compatible, though i am intending there to be an alternative to them that doesn't require that you use them even in the simple case.

@xster
xster force-pushed the nav-bar-title-2 branch 2 times, most recently from dfa8497 to 4e93955 Compare July 24, 2018 22:44
@xster
xster force-pushed the nav-bar-title-2 branch from 044abba to f5d2682 Compare July 25, 2018 01:41
@xster
xster requested review from Hixie and matthew-carroll July 25, 2018 01:41
@xster
xster force-pushed the nav-bar-title-2 branch from f5d2682 to 0649cd9 Compare July 27, 2018 21:25
/// If true and [leading] is null, automatically try to deduce what the [leading]
/// widget should be. If [leading] widget is not null, this parameter has no effect.
///
/// Specifically [CupertinoNavigationBar] would:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

i think maybe "will" would be better than "would" here

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

sg

/// 1. Show a 'Close' button if the current route is a `fullscreenDialog`.
/// 2. Show a back chevron with [previousPageTitle] if [previousPageTitle] is
/// not null.
/// 3. If the current route is a [CupertinoPageRoute] and the previous route

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

1 and 2 have the form "show ... if", but 3 has the form "if ... show", which is weird

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

changed

@@ -202,17 +257,19 @@ class CupertinoSliverNavigationBar extends StatelessWidget {
/// The [largeTitle] argument is required and must not be null.
const CupertinoSliverNavigationBar({

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

consider using macros for the docs on this class if they're identical to the other one

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Made templates for the ones that are mostly duplicate

left: 0.0,
right: 0.0,
bottom: 0.0,
child: new ClipRect(

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

can we avoid the cliprect? we're on a mission to remove all clips. they are too expensive.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

not really :S

Unfortunately GitHub doesn't show code moves. I just moved this block so this file flows better.

The large title actually needs to clip. I can't just hide it behind other things because the thing on top of it is translucent.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

ah well

}) {
// Auto use the CupertinoPageRoute's title if middle not provided.
if (title == null
&& automaticallyImplyTitle

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

usually we try to line up the expressions so the && would be on the end of the last line (it works better they way you've done it here when using return)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I don't have a strong opinion either way. Dartfmt seems to place them at the end. The end it is then.

if (title == null
&& automaticallyImplyTitle
&& currentRoute is CupertinoPageRoute
&& currentRoute.title?.isNotEmpty == true) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

why is an empty string special? Generally we make "null" special.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Nothing in particular. Changed to null.

&& currentRoute.title?.isNotEmpty == true) {
return new Text(currentRoute.title);
} else {
return title;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

return after else

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Done

// Auto use the CupertinoPageRoute's title if middle not provided.
if (title == null
&& automaticallyImplyTitle
&& currentRoute is CupertinoPageRoute

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

it's a pity this class has hard-coded knowledge of CupertinoPageRoute but i don't have a better solution

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Ya, as long as 'title' isn't a generic ModalRoute concept. We can introduce more abstraction like RouteTitleProvider.of(route) and have CupertinoPageRoute implement it but I think it's probably ok that the route and the nav bar is a bound concept like the uinavigationcontroller and the uinavigationitems inside uiviewcontrollers are bound concepts.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

yeah i think it's fine as you have it, just a minor blemish on an otherwise nice design.

);
} else {
return const SizedBox(height: 0.0, width: 0.0);
}

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

lots of returns-after-else in the last 30 lines

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Done. I left the if-else if-else at the end which seems more compact than a series of exits

} else if (route is CupertinoPageRoute<dynamic>) {
final CupertinoPageRoute<dynamic> cupertinoRoute = route;
return new ValueListenableBuilder<String>(
valueListenable: cupertinoRoute.previousTitle,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

this will always be a frame behind.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I'm not super sure I get this one. Isn't the route push/replace/etc -> didChangePrevious -> ValueNotifier.set -> notifyListeners -> setState chain all happening one frame before the widget being first built?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

you're right, i was wrong. for some reason i was thinking the listenable interface notified on microtasks, but that's streams, not listenables.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Added some code comments and a test

/// See also:
///
/// * [AnimatedBuilder], which invokes a builder on [Animation] ticks rather
/// than a [ValueListenable] changing value.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Specifically, this seems wrong. AnimatedBuilder doesn't invoke things based on Animation ticks, it's in fact more general than this class. It ticks on any Listenable.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

(this comment was meant to be on the other PR that includes this code)

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Right. Changed (in the other PR)

@xster
xster force-pushed the nav-bar-title-2 branch 3 times, most recently from d112f5b to 55fe8ee Compare August 10, 2018 17:38
@Hixie

Hixie commented Aug 15, 2018

Copy link
Copy Markdown
Contributor

Looks like you have a merge error here (see e.g. the top change on your PR).

@xster
xster force-pushed the nav-bar-title-2 branch 2 times, most recently from f1f3866 to ed31d97 Compare August 15, 2018 21:31
@xster

xster commented Aug 15, 2018

Copy link
Copy Markdown
Member Author

Cleaned up the const lints

@xster xster added the c: API break Backwards-incompatible API changes label Aug 22, 2018
@Hixie

Hixie commented Aug 23, 2018

Copy link
Copy Markdown
Contributor

LGTM modulo the comments on #20322

@xster
xster merged commit c418b2f into flutter:master Aug 24, 2018
@xster
xster deleted the nav-bar-title-2 branch August 24, 2018 01:24
@github-actions github-actions Bot locked as resolved and limited conversation to collaborators Aug 10, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

c: API break Backwards-incompatible API changes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants