Start Debugging
2026-01-08 flutter Edit on GitHub

Routing no Flutter 3.x: tp_router tenta apagar sua tabela de rotas (e é uma ideia interessante)

tp_router é um router de Flutter dirigido por gerador que elimina tabelas de rotas manuais. Anote suas páginas, rode build_runner e navegue com APIs tipadas em vez de caminhos baseados em string.

O routing do Flutter é uma daquelas coisas que você só nota quando dói. As primeiras telas são fáceis. Depois o app cresce, os paths evoluem, e “só adicionar mais uma rota” vira um imposto de manutenção. Em 7 de janeiro de 2026, um post da comunidade propôs uma solução opinada: tp_router, um router dirigido por gerador que mira em zero configuração manual de tabela de rotas.

Thread original: tp_router: Stop Writing Route Tables (r/FlutterDev)
Links do projeto: GitHub, pub.dev

O modo de falha: strings em todo lugar

A maioria dos times já viveu alguma versão disso:

// Define route table
final routes = {
  '/user': (context) => UserPage(
    id: int.parse(ModalRoute.of(context)!.settings.arguments as String),
  ),
};

// Navigate
Navigator.pushNamed(context, '/user', arguments: '42');

“Funciona”, até não funcionar: o nome da rota muda, o tipo do argumento muda, e você obtém crashes em runtime em partes do app que não tocou.

Anotação primeiro, geração depois

A proposta do tp_router é simples: anote a página, rode o gerador e depois navegue através de tipos gerados em vez de strings.

Do post:

@TpRoute(path: '/user/:id')
class UserPage extends StatelessWidget {
  final int id; // Auto-parsed from path
  final String section;

  const UserPage({
    required this.id,
    this.section = 'profile',
    super.key,
  });
}

// Navigate by calling .tp()
UserRoute(id: 42, section: 'posts').tp(context);

Essa última linha é todo o ponto: se você renomear section ou mudar id de int para String, você quer que o compilador quebre seu build, não seus usuários.

A pergunta real: mantém a fricção baixa conforme o app cresce?

Se você já usou auto_route, já sabe que routing dirigido por anotação pode funcionar bem, mas você ainda acaba escrevendo uma lista central:

@AutoRouterConfig(routes: [
  AutoRoute(page: UserRoute.page, path: '/user/:id'),
  AutoRoute(page: HomeRoute.page, path: '/'),
])
class AppRouter extends RootStackRouter {}

tp_router está tentando remover esse último passo por completo.

Colocando para rodar em um projeto Flutter 3.x

As dependências mostradas na thread são:

dependencies:
  tp_router: ^0.1.0
  tp_router_annotation: ^0.1.0

dev_dependencies:
  build_runner: ^2.4.0
  tp_router_generator: ^0.1.0

Gerar as rotas:

E conectar:

void main() {
  final router = TpRouter(routes: tpRoutes);
  runApp(MaterialApp.router(routerConfig: router.routerConfig));
}

Se você quer menos boilerplate de routing e mais segurança em tempo de compilação, vale a pena fazer um spike rápido com tp_router. Mesmo que você não adote, a direção é certa: trate navegação como API tipada, não como folclore baseado em string.

Comments

Sign in with GitHub to comment. Reactions and replies thread back to the comments repo.

< Voltar