CupertinoTabView is not hot reload friendly #43574
Comments
|
@pq here is the quick fix that we could suggest any time there is a closure within a build method to keep users writing code that will hot reload well even if there are bugs in widgets like there was for After: |
|
@DaveShuckerow you've been recommending this sort of pattern of refactors for unrelated style reasons while reviewing the DevTools in Flutter code. Would you like a general lint and quick fix for this case? |
|
This quick fix is certainly helpful, but it's hard to discover. Is there something we can do from the framework side or the VM side to make code in such a closure reloadable? Edit: I missed the pull request in my initial comment. I wonder how common a problem this is in other builder closures. |
|
#43585 |
|
Fyi @goderbauer I hear you are investigating some enhancements to routing that might make some code like this more amenable to hot reload. |
|
https://docs.google.com/document/d/1Q0jx0l4-xymph9O6zLaOY4d_f7YFpNWX_eGbzYxr9wY/edit#heading=h.l6kdsrb6j9id <-- navigator proposal that might enable code like this to be more easily hot-reloadable. |
|
Seems like the reason is each CupertinoTabView is a parallel navigation stack whose first page is really following https://api.flutter.dev/flutter/widgets/ModalRoute/buildPage.html
On the one hand, it's very similar to other edge triggered imperative calls like showDialog or showModalBottomSheet where you you rebuilt the 'parent' to the caller and changed the On the other hand, from the outside, this builder kinda looks very similar to CupertinoTabScaffold.tabBuilder which has no routes involved and does hot reload if the closure changes because it's entirely level-triggered. The fact that some builders are invoked once (indirectly) imperatively and some declaratively is indeed not obvious at all and confusing. CupertinoTabView.builder has some dartdoc but it's likely not enough. I think I'm leaning towards the change @jacob314 is proposing. Perhaps in addition, we should deprecate the builder arg and call it defaultRouteBodyBuilder (don't know what would be a good name) or some such to make it sound more level-triggered-y? |
|
Does Navigator 2.0 address this issue? |
|
I was able to reproduce this on latest flutter doctor -v |
|
Interesting, is the bug still there for many years? |
|
Reproducible on stable 3.3 and master 3.7 changing code sampleimport 'package:flutter/cupertino.dart';
import 'package:flutter/material.dart';
void main() => runApp(const MyApp());
class MyApp extends StatelessWidget {
const MyApp({super.key});
@override
Widget build(BuildContext context) {
return const CupertinoApp(
home: HomeScreen(),
);
}
}
class HomeScreen extends StatelessWidget {
const HomeScreen({super.key});
@override
Widget build(BuildContext context) {
return CupertinoTabScaffold(
backgroundColor: Colors.white,
tabBar: CupertinoTabBar(items: const [
BottomNavigationBarItem(
icon: Icon(CupertinoIcons.home),
label: 'Home',
),
BottomNavigationBarItem(
icon: Icon(CupertinoIcons.settings),
label: 'Settings',
),
]),
tabBuilder: (context, index) {
if (index == 0) {
return Center(
child: Text("Home Screen",
style: Theme.of(context).textTheme.headlineMedium),
);
} else {
return CupertinoTabView(
builder: (context) {
return Center(
// Changing the text style of the Text widget below requires a
// hot restart to see its effect.
child: Text("Settings Screen changed",
style: Theme.of(context).textTheme.headlineMedium),
);
},
);
}
},
);
}
}
flutter doctor -v (mac) |
Hot reload won't apply changes made to the
builderof a CupertinoTabView. A hot restart is required to see the effect of those changes. This was hit by participants in a UX study and no one had any clue about why hot reload stopped working. The code below can reproduce the issue:Cc: @jacob314 @Hixie
The text was updated successfully, but these errors were encountered: