perf: trazer o code splitting para a main (o #38 não chegou lá) - #47
Merged
Conversation
O frontend saia num chunk unico de 2,0 MB (597 kB gzip): quem abria a tela de login baixava a aplicacao inteira, incluindo o editor TipTap, os graficos e todas as telas de admin, para ver um formulario com dois campos. O Vite avisava disso a cada build. 41 rotas passam a entrar por lazy(), com um Suspense em volta. Login e Register ficam estaticos de proposito: sao o primeiro contato de quem chega sem sessao, e adiar essas duas trocaria o bundle grande por um flash de spinner logo na abertura. Carga inicial: 2400 kB -> 973 kB (649 kB -> 261 kB gzip), ~60% a menos. Medido no navegador: o login busca 26 chunks e o chunk do editor (570 kB, TipTap + ProseMirror + highlight.js, compartilhado por KBCreate e KBEdit) nao esta entre eles. Navegando para /forgot-password, o chunk proprio da rota e buscado sob demanda e a tela renderiza.
O gatilho tinha filtro 'branches: [main]' no pull_request, entao um PR empilhado sobre outra branch nao recebia nenhum check - foi o que aconteceu com este proprio PR, aberto sobre feat/i18n-telas-secundarias para evitar conflito no App.jsx. Sem checks, a protecao da main so cobre o PR de baixo da pilha: o de cima entra sem ninguem ter rodado teste nele.
Contributor
There was a problem hiding this comment.
Pull request overview
Este PR traz para a main o code splitting por rota (que tinha sido mesclado em uma branch “beco sem saída”) e ajusta o workflow de CI para que PRs empilhados (base != main) também recebam checks, evitando que mudanças passem sem validação.
Changes:
- Introduz
React.lazy()+Suspenseemfrontend/src/App.jsxpara carregar a maioria das rotas sob demanda. - Mantém Login/Register como imports estáticos (primeiro contato sem spinner).
- Remove o filtro de branch de destino no evento
pull_requestdo workflow.github/workflows/ci.ymlpara garantir CI em PRs empilhados.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| frontend/src/App.jsx | Aplica code splitting por rota com lazy()/Suspense e fallback de loading. |
| .github/workflows/ci.yml | Garante execução de CI em PRs com base diferente de main (PR empilhado). |
Suppressed comments (1)
frontend/src/App.jsx:108
PublicRoutetambem replica o spinner; comoCarregandoRota()ja existe no arquivo, vale reutilizar para manter comportamento/estilo consistente e evitar codigo duplicado.
};
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+112
to
+113
| <Suspense fallback={<CarregandoRota />}> | ||
| <Routes> |
Comment on lines
76
to
78
| const ProtectedRoute = ({ children }) => { | ||
| const { t } = useTranslation(); | ||
| const { isAuthenticated, loading } = useAuth(); |
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
O que aconteceu
O #38 está marcado como MERGED, mas o código nunca chegou na
main.Ele foi aberto sobre
feat/i18n-telas-secundariaspara evitar conflito noApp.jsx. A ordem dos merges inverteu o que eu esperava:feat/i18n-telas-secundarias→main) foi mesclado primeiroperf/code-splitting→feat/i18n-telas-secundarias) foi mescladodepois — numa branch que já tinha virado beco sem saída
O GitHub mostra os dois como MERGED, e é verdade: o #38 foi mesclado, só que
num destino que não leva mais a lugar nenhum.
Verificado na
mainantes deste PR:Ou seja: a redução de 60% no bundle e a correção do gatilho do CI não estão
em produção.
Este PR
Cherry-pick dos dois commits órfãos, agora direto sobre a
main:perf: dividir o bundle por rota— 41 rotas emlazy(), comSuspenseci: rodar tambem em PR que nao aponta para a main— sem isto, um PRempilhado não recebe check nenhum, que foi como o perf: dividir o bundle por rota (−60% na carga inicial) #38 passou sem CI de início
Aplicou limpo (o commit do splitting foi escrito sobre o mesmo
App.jsxqueestá na main hoje).
Verificação
npm test→ 7 passam ·vite buildoknpm test→ 38 passamSobre o processo
PR empilhado só é seguro se a ordem de merge for de baixo para cima. Foi má
escolha minha abrir assim sem deixar isso explícito no corpo do #38 — a
observação que coloquei lá dizia que o GitHub re-aponta a base sozinho, o que é
verdade quando o PR de baixo é mergeado primeiro, e eu não sinalizei a
dependência de ordem com clareza suficiente.
Depois de mergear este, dá para apagar
feat/i18n-telas-secundariaseperf/code-splitting: o conteúdo passa a estar todo aqui.