Problemas com rebuilds ao navegar? Acho que posso te ajudar.

Se quiser pular direto para o problema/solução pode seguir para a sessão “O que está rolando?”

Um pouco de contexto

Há alguns meses, participei de um projeto onde enfrentei um problema interessante: as telas eram sempre redesenhadas ao navegar, incluindo a abertura de Bottom Sheets, Dialogs, etc.

Acabamos por seguir uma abordagem “inusitada”, no mínimo, para contornar o problema. Perdemos dias pesquisando e tentando entender o que estava acontecendo, mas não encontramos nenhuma solução satisfatória.

O tempo passou, e eu continuei com minhas atividades, até que, em outro projeto, me deparei com o mesmo problema enquanto tentava atualizar o Flutter da versão 3.16.9 para a 3.19.6. Foi então que percebi que o problema poderia estar no Flutter e não na codebase em si.

“Google, meu amigo, venha cá por favor”

Com uma ideia mais clara da origem do problema, consegui realizar uma pesquisa mais assertiva e encontrei alguns insights que vou compartilhar aqui neste artigo.

O primeiro item que encontrei foi esta issue no repositório do Flutter.

Resumindo a thread da issue: várias pessoas estavam enfrentando problemas semelhantes ao atualizar para a versão 3.19.X do Flutter. Em um dos comentários, foi compartilhado um snippet de código para simular o problema, mas vou trazer um exemplo mais detalhado adiante.

Continuando a pesquisa, acabei esbarrando em um fórum japonês com uma explicação mais profunda sobre o problema. Foi através dele que consegui resolver o problema. Mas você pode estar se perguntando:

O que está rolando?

Devido a algumas alterações mergeadas nesse PR, o problema começou a ocorrer.

Mais especificamente essa alteração no arquivo packages/flutter/lib/src/widgets/routes.dart

 @override void didChangeNext(Route<dynamic>? nextRoute) { super.didChangeNext(nextRoute); changedInternalState(); } @override void didPopNext(Route<dynamic> nextRoute) { super.didPopNext(nextRoute); changedInternalState(); }

De forma resumida, sempre que uma navegação é feita, o método changedInternalState é chamado. Ele tem ligação direta com o ModalRoute. E o que é isso? Eu te explico em seguida.

Imagine o seguinte cenário:

Se da tela /second você navegar para outra, abrir um dialog ou bottom sheet, a segunda tela será redesenhada. Isso não acontecia antes da versão 3.19.

Veja o exemplo abaixo:

Agora veja quantas vezes as telas foram reconstruídas:

flutter: BUILD FIRST PAGE
flutter: BUILD SECOND PAGE
flutter: BUILD THIRD PAGE
flutter: BUILD SECOND PAGE
flutter: BUILD MODAL BOTTOM SHEET
flutter: BUILD THIRD PAGE
flutter: BUILD THIRD PAGE
flutter: BUILD SECOND PAGE

Isso pode ter vários efeitos colaterais, principalmente ligados a desempenho, até consumo de recursos desnecessários, como múltiplas chamadas a uma API, por exemplo.

Tudo isso acontece devido ao uso do ModalRoute para obter argumentos vindos da navegação. A primeira rota está declarada como constante nos routes que configuramos acima, o que evita esse comportamento. No entanto, para todas as rotas que estiverem na pilha de navegação e não forem constantes, o problema ocorrerá.

Como resolver? Ou não. Hehehe

No fórum japonês mencionado anteriormente, há uma implementação paliativa de um MyModalRoute. Funciona, já testei.

class MyModalRoute { static ModalRoute<dynamic>? of(BuildContext context) { ModalRoute<dynamic>? route; context.visitAncestorElements((element) { if(element.widget.runtimeType.toString() == '_ModalScopeStatus') { dynamic widget = element.widget; route = widget.route as ModalRoute; return false; } return true; }); return route; }
}

Ao alterar as rotas para usar essa nova implementação de MyModalRoute, o problema é contornado.

final args = MyModalRoute.of(context)!.settings.arguments; return SecondPage( args: args,
);

No entanto, como alguns podem imaginar, essa é uma solução que traz para nossas mãos a responsabilidade de manutenção no futuro. Afinal, o ModalRoute é parte da SDK do Flutter, e agora temos nosso próprio.

A melhor solução que encontrei foi a seguinte: utilizar o onGenerateRoute no lugar do routes do MaterialApp.

Diferente do routes, o onGenerateRoute é uma função que retorna uma Route, não somente um Widget como é padrão do routes.

A solução para o problema do exemplo acima seria:

onGenerateRoute: (settings) { switch (settings.name) { case '/': return MaterialPageRoute( settings: settings, builder: (c) => const FirstPage(), ); case '/second': return MaterialPageRoute( builder: (context) { final args = settings.arguments; return SecondPage(args: args); }, settings: settings, );

Assim, o problema não acontece mais, e continuamos utilizando ferramentas nativas da SDK do Flutter.

Espero ter ajudado alguém que esteja quebrando a cabeça com esse problema.

Vlw galerinha!