A esta altura, você já deve ter ouvido falar sobre os Componentes Dinâmicos que são super úteis para criar aplicações mais dinâmicas. Eles nos permitem carregar componentes dinamicamente em tempo de execução, dependendo de alguma lógica personalizada, sem ter que criar um componente que esteja sobrecarregado com cargas de ngIfs.

Se você ainda não ouviu falar sobre Componentes Dinâmicos, sugiro que assista a esta palestra de Shmuela Jacobs no Angular Connect:

No meu trabalho diário, estou construindo um sistema que é como um CRM gerenciando vários produtos diferentes, todos com uma parte central comum, mas também algumas coisas específicas do produto. Para tornar os componentes mais reutilizáveis, introduzi componentes dinâmicos aqui e ali, que carregam o componente específico do produto correto, dependendo de um InjectionToken que especifica o produto ativo atual. Tudo estava bom e bom, até que tentei refatorar um fluxo de etapas que tem algumas etapas comuns, mas também algumas etapas específicas do produto. Isso foi um problema porque o fluxo de etapas não é apenas baseado em componentes, mas também depende de rotas. Ou seja, o step-flow de um produto pode ter algumas etapas adicionais, ou seja, rotas, que são diferentes das demais. O número de etapas também pode variar.

Uma solução suja seria criar um número fixo de rotas denominadas: step1, step2, step3 e, em seguida, carregar o componente dinamicamente em cada etapa, mas como o número de etapas varia, isso não é possível. A solução certa é usar o roteamento dinâmico .

Normalmente definimos as rotas de um módulo de forma muito estática em um módulo de roteamento como este:

Uma vez que o módulo é carregado não há lógica que possa interferir na atribuição estática das rotas, então sempre haverá a rota inicial e nada mais.

Exemplo

Vejamos um exemplo bem simplificado que pode não fazer muito sentido, mas tem o objetivo de demonstrar como o roteamento dinâmico funciona:

Queremos criar uma aplicação com as seguintes rotas:

• Início (estático)
• 404 Não encontrado (estático)
• Dia (dinâmico; disponível apenas entre 6h e 18h)
• Noite (dinâmico; disponível apenas entre 18h e 6h)
• Segredo (dinâmico; chance de 50/50)

Agora que definimos nossas rotas na seção de provedores, podemos usar o objeto de definição de provedor useFactory . Dessa forma podemos passar uma fábrica que contém a lógica que decide como devem ser as rotas.

Breve lembrete: Se você carregou o módulo às 5h59 e esperou até as 6h01, a rota dos dias não estará disponível, pois a configuração da rota já foi feita anteriormente. Isso significa que a lógica que define as rotas só acontece uma vez quando o módulo é carregado.

Conclusão

Espero poder mostrar-lhe algo novo e interessante. Se você estiver interessado em Angular, confira meus outros posts no Medium.

O exemplo completo está disponível no meu GitHub: