DEV Community: Antoniel Magalhães

Seu time não merece revisar seu PR

Antoniel Magalhães — Sat, 07 Mar 2026 02:34:58 +0000

TL;DR Como usar IA e stacked PRs para facilitar a vida do seu time na revisão de um PR grande.

Publicado originalmente em antoniel.sh.

O problema

Você abre um PR e percebe que ele tem algo em torno de 10 mil linhas de mudança. Nesse ponto, o problema não é só o tamanho do código. É a experiência de review. Um PR desse tamanho é difícil de entender, fácil de adiar e fácil de revisar mal.

Em retrospecto, isso deveria ter sido uma stack desde o começo.

Stacked PRs

A primeira explicação clara de stacked PRs que vi foi na talk do Tomas Reimers na GitKon 2022 sobre o tema: Stacked Pull Requests | GitKon 2022 | Tomas Reimers, Graphite. A ideia é simples: em vez de um PR gigante, você cria uma sequência de PRs menores, em que cada um se apoia no anterior.

Graphite é uma das ferramentas associadas a esse workflow, mas a ideia principal independe da ferramenta. Uma stack é mais fácil de revisar porque cada PR carrega uma parte da história.

Um PR gigante	Stacked PRs
Um review com contexto demais	Vários reviews com limites claros
Refactors e feature work misturados	Cada PR carrega uma parte da mudança
Fácil de adiar ou revisar por cima	Mais fácil de revisar em ordem

Um guia prático

Idealmente, você planeja a stack desde o começo e agrupa as mudanças por entrega. Mas às vezes você só percebe o problema quando o PR já está grande demais. Nesse caso, a IA pode ajudar a quebrar a branch em uma stack revisável com muito menos trabalho manual.

Peça para a IA dividir a branch em stacked PRs.
Valide que a branch final da stack preserva a mudança original.
Peça para a IA gerar o fluxo de gh para abrir os PRs em ordem.

Usando IA para criar a stack

Esse é um daqueles casos em que o prompt pode continuar simples.

My branch against main has a huge diff. Split it into stacked PRs. Create the branches locally and I will push them.

O resultado pode voltar em um formato como este:

I split the branch into 5 stacked PRs.

Merge order:
1. stacked (foundation)
2. 02-api-cleanup (base: stacked)
3. 03-shared-types (base: 02-api-cleanup)
4. 04-backend-flow (base: 03-shared-types)
5. 05-frontend-flow (base: 04-backend-flow)

Como validar que nada se perdeu

A verificação que importa

Quando a IA propõe a stack, o próximo passo é validar.

I need a quick way to compare the original branch with the final stacked branch and verify that nothing important was lost.

Isso te dá um comando como este:

git --no-pager diff main <original-branch> --shortstat && echo "" && git --no-pager diff main <last-stacked-branch> --shortstat

Se os dois resumos forem efetivamente iguais, a branch final da stack preserva a mudança original. Pequenas diferenças de formatação são aceitáveis; o formato geral do diff deve continuar o mesmo.

61 files changed, 10234 insertions(+), 487 deletions(-)
61 files changed, 10240 insertions(+), 492 deletions(-)

Automatizando a abertura dos PRs com gh CLI

Depois que o diff confere, o problema restante é operacional: abrir cada PR e configurar a base correta.

O fluxo com `gh`

I already have the stacked branches. Give me a gh CLI flow to open the PRs in order and set each base branch correctly.

Faça push de todas as branches primeiro e depois use o fluxo gerado com gh:

PR1=$(gh pr create --base main --head <stacked-1> --title "[1/5] Foundation changes" --body "Stack 1 of PROJECT-123" | grep -oE '[0-9]+$')
PR2=$(gh pr create --base <stacked-1> --head <stacked-2> --title "[2/5] API cleanup" --body "Depends on #$PR1" | grep -oE '[0-9]+$')
PR3=$(gh pr create --base <stacked-2> --head <stacked-3> --title "[3/5] Shared types" --body "Depends on #$PR2" | grep -oE '[0-9]+$')
PR4=$(gh pr create --base <stacked-3> --head <stacked-4> --title "[4/5] Backend flow" --body "Depends on #$PR3" | grep -oE '[0-9]+$')
gh pr create --base <stacked-4> --head <stacked-5> --title "[5/5] Frontend flow" --body "Depends on #$PR4"

Cada gh pr create retorna a URL do PR; grep -oE '[0-9]+$' extrai o número para o próximo Depends on #N.

A lição

Se o trabalho pertence a uma stack, faça uma stack. Idealmente, desde o começo. Se você percebeu tarde demais, peça ajuda para a IA dividir, validar e abrir os PRs.

Stop F*cking Your Team With Giant PRs

Antoniel Magalhães — Sat, 07 Mar 2026 02:33:18 +0000

Originally published on antoniel.sh.

TL;DR How to use AI and stacked PRs to make life easier for your team when reviewing a large PR.

The problem

You open a PR and realize it has around 10k lines of changes. At that point, the problem is not only the code size. It is the review experience. A PR that large is hard to reason about, easy to postpone, and easy to review poorly.

In retrospect, it should have been a stack from the start.

Stacked PRs

The first clear explanation of stacked PRs I saw was in Tomas Reimers's GitKon 2022 talk on the topic: Stacked Pull Requests | GitKon 2022 | Tomas Reimers, Graphite. The idea is simple: instead of one giant PR, you create a sequence of smaller PRs where each one builds on the previous one.

Graphite is one of the tools associated with that workflow, but the key idea is independent of any tool. A stack is easier to review because each PR carries one part of the story.

One huge PR	Stacked PRs
One review with too much context	Multiple reviews with clear boundaries
Refactors and feature work mixed together	Each PR carries one part of the change
Easy to postpone or skim	Easier to review in order

A practical guide

Ideally, you plan the stack from the beginning and group changes by delivery. But sometimes you only notice the problem when the PR is already too large. In that case, AI can help you break the branch into a reviewable stack with much less manual work.

Ask AI to split the branch into stacked PRs.
Validate that the final stacked branch preserves the original change.
Ask AI to generate the gh flow to open the PRs in order.

Using AI to stack PRs

This is one of those cases where the prompt can stay simple.

My branch against main has a huge diff. Split it into stacked PRs. Create the branches locally and I will push them.

The result can come back in a format like this:

I split the branch into 5 stacked PRs.

Merge order:
1. stacked (foundation)
2. 02-api-cleanup (base: stacked)
3. 03-shared-types (base: 02-api-cleanup)
4. 04-backend-flow (base: 03-shared-types)
5. 05-frontend-flow (base: 04-backend-flow)

How to validate nothing was lost

The check that matters

Once the AI gives you a proposed stack, the next step is validation.

I need a quick way to compare the original branch with the final stacked branch and verify that nothing important was lost.

That gives you a command like this:

git --no-pager diff main <original-branch> --shortstat && echo "" && git --no-pager diff main <last-stacked-branch> --shortstat

If both summaries are effectively the same, the stacked branch preserves the original change. Small formatting differences are fine; the overall shape of the diff should remain the same.

61 files changed, 10234 insertions(+), 487 deletions(-)
61 files changed, 10240 insertions(+), 492 deletions(-)

Automating PR creation with gh CLI

Once the diff checks out, the remaining problem is operational: opening each PR and setting the right base branch.

The `gh` flow

I already have the stacked branches. Give me a gh CLI flow to open the PRs in order and set each base branch correctly.

Push all branches first, then use the generated gh flow:

PR1=$(gh pr create --base main --head <stacked-1> --title "[1/5] Foundation changes" --body "Stack 1 of PROJECT-123" | grep -oE '[0-9]+$')
PR2=$(gh pr create --base <stacked-1> --head <stacked-2> --title "[2/5] API cleanup" --body "Depends on #$PR1" | grep -oE '[0-9]+$')
PR3=$(gh pr create --base <stacked-2> --head <stacked-3> --title "[3/5] Shared types" --body "Depends on #$PR2" | grep -oE '[0-9]+$')
PR4=$(gh pr create --base <stacked-3> --head <stacked-4> --title "[4/5] Backend flow" --body "Depends on #$PR3" | grep -oE '[0-9]+$')
gh pr create --base <stacked-4> --head <stacked-5> --title "[5/5] Frontend flow" --body "Depends on #$PR4"

Each gh pr create returns the PR URL; grep -oE '[0-9]+$' extracts the number for the next Depends on #N.

The lesson

If the work belongs in a stack, make it a stack. Ideally, do it from the beginning. If you notice too late, ask AI to help you split, validate, and open the PRs.

Meu Processo de Agentic Engineering: Do Vibe Code ao BDD

Antoniel Magalhães — Thu, 05 Mar 2026 15:44:00 +0000

TL;DR Uso BDD para transformar especificação em código validado. Os cenários definem o comportamento; os testes cobrem; a mutação confere se os testes são de fato úteis. Depois de validado, consigo refatorar a implementação sem medo de regressão.

Introdução

Este post trata de como eu atualmente lido com agentic engineering e de como tento criar features usando agentes de IA (Cursor, Claude Code, ou qualquer outro) por meio de uma metodologia definida, especificamente BDD (Behavior Driven Design) para guiar a produção de código e garantir a corretude.

Vibe Code vs Agent Engineering

A primeira vez que vi o termo agentic engineering aparecer foi no artigo do Simon Willison sobre padrões de agentic engineering. Eu já praticava isso, mas continuava chamando de vibe coding e eu gostei da nomenclatura, parece algo mais sério e bem definido.

Vibe coding

Quando você não presta atenção no código de forma geral

Não presta atenção em como as coisas estão sendo feitas. O foco está em entregar, não em estabelecer padrões ou validar a qualidade do que o agente produz.

Agentic engineering

Quando você cria e estabelece normas

Cria normas, guidelines e define as formas como quer que o código seja escrito pela IA. Você ainda não digita; mas influencia ativamente como o código é produzido.

Explorando novos padrões de agentic engineering

No dia a dia, é difícil abrir mão de produtividade ou qualidade em relação à baseline só para experimentar padrões de agentic engineering. Então o que faço normalmente é criar pequenos side projects que quero fazer e usá-los para explorar essas capacidades com o agente.

Comecei o projeto com meu workflow já estabelecido de agentic engineering que é: eu tenho uma intenção, crio uma especificação usando SpecKit ou OpenSpec, a partir da especificação eu crio um plano, e desse plano eu crio a implementação.

Intenção → Especificação → Plano → Implementação

Um pipeline simples, mas que funciona bem para mim. O "problema" é que preciso estar atento em todas as etapas: a intenção está na minha mente; tenho que confirmar que a especificação reflete o que imaginei; verificar se o plano de implementação segue como eu imaginei; e no final fazer code review da implementação. Esse é um processo que exige bastante da minha atenção e minha vontade era explorar diferentes padrões que pudessem reduzir o meu tempo de atenção por tarefa mas mantendo a mesma qualidade.

TDD

Já tinha visto o padrão de usar testes automatizados para validar a implementação e criar essa contrapressão no agente para que ele valide o próprio trabalho. Acho válido. O problema, na minha experiência, é que quando deixo o agente criar os testes sozinho, sem supervisão adequada, ele acaba pegando atalhos: testes que cobrem coisas triviais e detalhes de implementação. Coisas como expect(1).toBe(1) e afins.

O Simon documenta o padrão de TDD com red/green em seu guia: fazer o teste falhar e depois fazê-lo passar, garantindo que o teste é realmente útil. Dada a minha experiência, ainda não me sentia à vontade confiando na boa vontade do agente de não editar o teste só para fazê-lo passar (@effectfully). Meu pior cenário: implemento TDD, levo n minutos, vou revisar o código, especificamente os testes e os testes não fazem sentido ou faço um teste manual e descubro que a feature não funciona, e os testes passam.

Antes: Just Go

Fluxo anterior sem especificação formal

Abrir o agente, explicar a tarefa, refinar ao longo das iterações. Sem spec, sem validação formal. O risco: testes triviais, implementação que passa mas não entrega o esperado.

Explicar tarefa → Agente implementa → Revisar → OK? → (Não → Agente implementa) | (Sim → Pronto)

Depois: BDD

Especificação para ação

Spec → .feature → tony-bdd-test → mutação. Cenários aprovados viram fonte de verdade; testes validam comportamento; mutação garante que os testes não passam por acaso.

Spec → .feature → tony-bdd-test → Mutação

BDD

Há um tempo atrás, em tempos pré-llms, me deparei com um requisito: como garantir a qualidade do código através de testes que conversam com o produto? Havia um descompasso entre o que era pedido no ticket e o que o time entregava. A solução: BDD (Behavior Driven Design), documentado pela Cucumber. Uma vez aprovados os arquivos .feature e os cenários, o time teria de garantir que os testes de cada cenário estivessem passando.

Essa ideia voltou à medida que o meu side project ia crescendo. O tempo de validar todas as features aumentava na mesma medida em que eu adicionava funcionalidades. A pergunta reapareceu: como consolidar o que tenho agora e garantir que eu possa adicionar coisas novas de forma estruturada, com testes que de fato validem o comportamento?

BDD. Meu approach foi criar dois /commands no Cursor: um para gerar o .feature e outro para implementar a feature e seus testes.

/tony-bdd

O comando pega um arquivo (um componente, uma rota, um handler) e extrai dele os cenários que importam. Em vez de organizar por página ou tela, organiza por domínio: auth, checkout, layout, o que fizer sentido pro vocabulário do código. Começa com poucos cenários de alto impacto, os journeys que provam que a coisa funciona ponta a ponta. Só depois, se precisar, desdobra em regras e variações. Cada cenário ganha um @id estável. Um script varre os .feature e verifica se há teste correspondente a cada cenário declarado. Não usa Cucumber; os .feature são só a fonte de comportamento. O comando não toca em código nem em testes, só escreve specs.

/tony-bdd-test

Já esse comando pega os cenários Gherkin e implementa os testes. Coloca os testes ao lado do código sob teste, com mocks mínimos (MSW quando for web). Para cada teste que escreve, exige um sanity-check por mutação: quebra a implementação de propósito, roda o teste, confirma que falha, reverte. O objetivo é garantir que os testes não passem por acaso.

tony-bdd (.feature) → tony-bdd-test (Testes) → Mutação → Teste falha? → (Sim → Reverte → Pronto) | (Não → Reforça → Mutação)

/tony-workflow

Os comandos base permitem criar .features e implementá-las. Como encadear os dois? É aí que entra o /tony-workflow. O workflow roda o /tony-bdd e depois o /tony-bdd-test, mas se aproveita da engenharia de contexto e subagents. Uma das instruções é paralelizar sempre que possível. Para features que lidam com partes diferentes do sistema ou que podem ser divididas em unidades de trabalho menores, uma vez gerados os .feature, cada um pode ser lançado em um subagent em paralelo, em background. Não bloqueia a thread principal nem polui o contexto principal.

Thread principal: tony-bdd → .feature
                         ↓
    ┌────────────────────┼────────────────────┐
    ↓                    ↓                    ↓
Subagent 1          Subagent 2          Subagent N
    ↓                    ↓                    ↓
tony-bdd-test       tony-bdd-test       tony-bdd-test
    └────────────────────┼────────────────────┘
                         ↓
                    background

Specs First vs BDD

Então BDD é melhor que o spec first? Não. Na prática eles podem ser usados juntos. Você pode gerar a especificação (SpecKit, OpenSpec) e definir o que deve ser construído. Depois, esse spec vira insumo pro tony-bdd. Os cenários .feature nascem desse material. O spec diz o quê; o BDD extrai o comportamento testável.

Conclusão

Essa metodologia não lida com ensinar ao agente como você quer que o código seja escrito. Ela cria ferramentas para garantir que, uma vez que o código está certo e validado, você não terá regressões ao longo do tempo. Esse workflow deve ser usado junto com outras técnicas: skills, rules, guardrails, agents.md.

Meu resultado: uma vez que o resultado está pronto e validado manualmente, revisar as interfaces criadas, os testes e a implementação leva menos tempo do que se eu tivesse que revisar tudo no Spec First. Por quê? Porque com tudo validado, testes prontos e implementação correta, posso trocar a implementação livremente. O que testo é a interface, não os detalhes internos. Isso me dá flexibilidade para refatorar sem medo pois está tudo coberto por testes. Se chegar ao ponto em que eu olho a implementação e percebo que não ficou tão boa quanto poderia ser; posso alterá-la completamente sabendo que os testes garantem o comportamento.

Resultados

Esses números vêm do projeto em que apliquei o workflow BDD. O coverage do Vitest cruza os cenários dos .feature com os relatórios de cobertura; o valor 0 em Uncovered indica que todos os cenários têm ao menos algum teste associado; nenhum ficou sem cobertura.

Métrica	Valor
Arquivos de feature	19
Cenários BDD	94
Arquivos de teste	15
Testes	176
Coverage (Vitest)	42%

Apesar de 42% ser uma cobertura baixa, a ideia não é ser exaustivo nos testes, mas preciso no que testar: garantir o comportamento que importa, não cobrir cada linha.

Referências

My Agentic Engineering Process: From Vibe Code to BDD

Antoniel Magalhães — Thu, 05 Mar 2026 15:38:05 +0000

TL;DR I use BDD to turn specification into validated code. Scenarios define behavior; tests cover it; mutation checks that tests are actually useful. Once validated, I can refactor the implementation without fear of regression.

Introduction

This post is about how I currently approach agentic engineering and how I try to build features using AI agents (Cursor, Claude Code, or any other) through a defined methodology—specifically BDD (Behavior Driven Design) to guide code production and ensure correctness.

Vibe Code vs Agent Engineering

The first time I saw the term agentic engineering was in Simon Willison's article on agentic engineering patterns. I was already doing it, but kept calling it vibe coding; I liked the new name—it sounds more serious and well-defined.

Vibe coding

When you don't pay attention to the code in general

You don't pay attention to how things are being done. The focus is on shipping, not on establishing patterns or validating the quality of what the agent produces.

Agentic engineering

When you create and establish norms

You create norms, guidelines, and define how you want the code to be written by the AI. You still don't type; but you actively influence how the code is produced.

Exploring new agentic engineering patterns

Day to day, it's hard to give up productivity or quality relative to the baseline just to experiment with agentic engineering patterns. So what I usually do is create small side projects I want to build and use them to explore these capabilities with the agent.

I started the project with my established agentic engineering workflow: I have an intention, I create a specification using SpecKit or OpenSpec, from the specification I create a plan, and from that plan I create the implementation.

Intention → Specification → Plan → Implementation

A simple pipeline, but it works well for me. The "problem" is that I need to pay attention at every step: the intention is in my mind; I have to confirm the specification reflects what I imagined; verify the implementation plan follows what I imagined; and finally do code review of the implementation. This is a process that demands a lot of my attention, and I wanted to explore different patterns that could reduce my attention time per task while keeping the same quality.

TDD

I had already seen the pattern of using automated tests to validate the implementation and create that counterpressure on the agent so it validates its own work. I think it's valid. The problem, in my experience, is that when I let the agent create tests on its own, without adequate supervision, it ends up taking shortcuts: tests that cover trivial things and implementation details. Things like expect(1).toBe(1) and the like.

Simon documents the red/green TDD pattern in his guide: make the test fail first, then make it pass, ensuring the test is actually useful. Given my experience, I still didn't feel comfortable trusting the agent's goodwill not to edit the test just to make it pass (@effectfully). My worst case: I implement TDD, spend n minutes, go to review the code, specifically the tests, and the tests don't make sense—or I run a manual test and discover the feature doesn't work, yet the tests pass.

Before: Just Go

Previous flow without formal specification

Open the agent, explain the task, refine over iterations. No spec, no formal validation. The risk: trivial tests, implementation that passes but doesn't deliver what's expected.

Explain task → Agent implements → Review → OK? → (No → Agent implements) | (Yes → Done)

After: BDD

Specification to action

Spec → .feature → tony-bdd-test → mutation. Approved scenarios become the source of truth; tests validate behavior; mutation ensures tests don't pass by accident.

Spec → .feature → tony-bdd-test → Mutation

BDD

A while back, in pre-LLM times, I ran into a requirement: how to ensure code quality through tests that talk to the product? There was a gap between what was asked in the ticket and what the team delivered. The solution: BDD (Behavior Driven Design), documented by Cucumber. Once the .feature files and scenarios were approved, the team would have to ensure the tests for each scenario were passing.

That idea came back as my side project grew. The time to validate all features increased in step with the functionality I added. The question reappeared: how do I consolidate what I have now and ensure I can add new things in a structured way, with tests that actually validate behavior?

BDD. My approach was to create two /commands in Cursor: one to generate the .feature and another to implement the feature and its tests.

/tony-bdd

The command takes a file (a component, a route, a handler) and extracts the scenarios that matter from it. Instead of organizing by page or screen, it organizes by domain: auth, checkout, layout, whatever makes sense for the code's vocabulary. It starts with few high-impact scenarios, the journeys that prove the thing works end-to-end. Only later, if needed, it unfolds into rules and variations. Each scenario gets a stable @id. A script sweeps the .feature files and checks that there's a corresponding test for each declared scenario. It doesn't use Cucumber; the .feature files are just the behavior source. The command doesn't touch code or tests, it only writes specs.

/tony-bdd-test

This command takes the Gherkin scenarios and implements the tests. It places tests next to the code under test, with minimal mocks (MSW when it's web). For each test it writes, it requires a sanity-check by mutation: break the implementation on purpose, run the test, confirm it fails, revert. The goal is to ensure tests don't pass by accident.

tony-bdd (.feature) → tony-bdd-test (Tests) → Mutation → Test fails? → (Yes → Revert → Done) | (No → Reinforce → Mutation)

/tony-workflow

The base commands allow creating .features and implementing them. How to chain the two? That's where /tony-workflow comes in. The workflow runs /tony-bdd and then /tony-bdd-test, but leverages context engineering and subagents. One of the instructions is to parallelize whenever possible. For features that touch different parts of the system or can be split into smaller work units, once the .feature files are generated, each can be launched in a subagent in parallel, in the background. It doesn't block the main thread nor pollute the main context.

Main thread: tony-bdd → .feature
                    ↓
    ┌───────────────┼───────────────┐
    ↓               ↓               ↓
Subagent 1      Subagent 2      Subagent N
    ↓               ↓               ↓
tony-bdd-test  tony-bdd-test   tony-bdd-test
    └───────────────┼───────────────┘
                    ↓
               background

Specs First vs BDD

So is BDD better than spec first? No. In practice they can be used together. You can generate the specification (SpecKit, OpenSpec) and define what should be built. Then that spec becomes input for tony-bdd. The .feature scenarios are born from that material. The spec says what; BDD extracts the testable behavior.

Conclusion

This methodology doesn't deal with teaching the agent how you want the code to be written. It creates tools to ensure that, once the code is correct and validated, you won't have regressions over time. This workflow should be used together with other techniques: skills, rules, guardrails, agents.md.

My result: once the outcome is ready and manually validated, reviewing the created interfaces, tests, and implementation takes less time than if I had to review everything in Spec First. Why? Because with everything validated, tests in place, and correct implementation, I can change the implementation freely. What I test is the interface, not the internals. That gives me flexibility to refactor without fear since it's all covered by tests. If I reach the point where I look at the implementation and see it's not as good as it could be, I can change it completely knowing the tests guarantee the behavior.

Results

These numbers come from the project where I applied the BDD workflow. Vitest coverage crosses the .feature scenarios with coverage reports; the 0 in Uncovered indicates that all scenarios have at least one associated test; none were left without coverage.

Metric	Value
Feature files	19
BDD scenarios	94
Test files	15
Tests	176
Coverage (Vitest)	42%

Although 42% is low coverage, the idea isn't to be exhaustive in tests, but precise in what to test: ensure the behavior that matters, not cover every line.

References

Entendendo useState e useReducer

Antoniel Magalhães — Mon, 01 Feb 2021 22:08:27 +0000

Introdução

O estado em uma aplicação react é um faz parte dos conceitos fundamentais da biblioteca, desde a adoção dos hooks na versão 16.8 temos dois hooks que tem a função de lidar com estados, o useState e o useReducer. Nesse post eu vou tentar dar uma breve explicação sobre cada um dos hooks e suas particularidades;

useState

De acordo com @types/react o hook useState possui a seguinte tipagem:

function useState<S>(initialState: S | (() => S)): [S, Dispatch<SetStateAction<S>>];

O useState recebe um parâmetro, o initialState
- Esse parâmetro pode ser um valor do tipo S ou uma função que retorna o tipo S, que é um tipo genérico ou seja, assume o tipo do seu estado, podendo ser um numero, string, ou um objeto qualquer.
O useState retorna uma array de duas posições
1. S se refere ao estado atual
2. Dispatch> é a função que vai atualizar aquele componente, o dispatch pode receber o valor que o estado vai ser atualizado ou um callback do tipo ((prevState: S) => S); recebendo o estado anterior e retornando o estado atual.

useReducer

Ainda de acordo com @types/react o hook useReducer possui a seguinte tipagem,A estrutura básica do useReducer é uma função que recebe entre 2 e 3 parâmetros e retorna um array de duas posições:

  function useReducer<R extends Reducer<any, any>, I>(                                  
            reducer: R,                                                                       
            initializerArg: I,                                                                
            initializer: (arg: I) => ReducerState<R>                                          
        ): [ReducerState<R>, Dispatch<ReducerAction<R>>]; 
)

Os parâmetros do useReducer:

Reducer é um callback com a seguinte estrutura: (prevState: S, action: A) => S;, esse callback é o responsável por atualizar o estado, seria o equivalente ao SetStateAction do useState, porém com suas particularidades, a exemplo o parâmetro do callback, o action, nele é possível definir o tipo da ação, passar dados através do payload, o reducer deve ficar mais claro durante os exemplos.
O initializerArg assim como initialState do useState é o parâmetro que vai receber o estado inicial do estado.
O initializer, esse recebe uma função responsável por modificar o initializeArg durante a montagem do componente modificando o estado inicial do reducer.

O useReducer retorna um array com 2 parâmetros: [ReducerState<R>, Dispatch<ReducerAction<R>>]

O primeiro parâmetro é o State do useReducer
O segundo parâmetro é a função que vai chamar o reducer (1º parâmetro do useReducer), recebendo parâmetro action, onde no retorno do reducer o state é atualizado.

Exemplos

partindo do caso de uso que o nosso estado é uma lista de jogadores, como podemos modificar essa lista utilizando o useState e o useReducer.

useState

/* No caso do useState se quisermos alterar esse estado em um componente abaixo podemos passar o setPlayer como prop. e montar o callback no componente abaixo, ou montar o addPlayer e passa-lo como prop. */

const [players, setPlayers] = useState(initialState); 
const addPlayer = (newPlayer) => {
  setPlayers([...players, newPlayer])
}
// Como o setPlayers vai ser chamado 👇
addPlayers('Ronaldo')

useReducer

/* Com o useReducer uma vez que defnimos a função reducer e suas ações passamos simplesmente o dispatch para baixo na arvore de componentes e cada componente chama a sua respectiva ação */

const reducer = (state, action) => {
    switch (action.type) {
      case "addPlayer": {
        const newState = [...state, action.payload];
        return newState;
      }
      default:
    }
  }
 const [players, dispatch] = useReducer(reducer, initialArg);
// Como o reducer vai ser chamado 👇
dispatch({ type : addPlayer, payload : "Ronaldo" })

Os dois códigos acima fazer a exatamente a mesma coisa, o useReducer parece muito mais verboso e compelxo que o useState, quais suas vantagens ? imagine uma situação que muitos outros métodos, adicionar, remover, atualizar... e ainda com outros estados como estado de loading, error entre outros. Como fariamos essas outras funções acessíveis para os componentes que a consomem ? criariamos uma nova prop para cada função, até setia possível mas imagina o caos que não seri esse componente, o useReducer aparece nesses casos onde você precisa lidar com muitos métodos e estados de um componente, a função reducer poderia ficar em um arquivo separado aumentando a qualidade e legibilidade do código, você saberia exatamente em qual tipo de action modificar, e ao invés de passar cada método com uma nova prop você pode passar só o dispatch e cada componente chama o tipo de ação que precisar.

Quando você precisa lidar com apenas um estado, é mais simples conveniente utilizar o useState ao invés do use Reducer apenas um estado para

References

React Documentation

Consumindo uma API no React

Antoniel Magalhães — Mon, 01 Feb 2021 02:04:20 +0000

Contexto

O código dessa aplicação está nesse link, o resultado final se encontra aqui.

Uma duvida muito comum quando se inicia no desenvolvimento web é como fazer aplicações o backend e o frontend se comunicarem. Como que eu posso fazer minha aplicação react se comunicar com minha API ? Essas são as dúvidas que eu vou tentar responder brevemente com esse post.

Como ?

A comunicação entre essas partes do sistema pode ser feita a partir do método http, que é um protocolo de comunicação onde através dele é possível a comunicação entre os diferentes pontos de um sistema. O protocolo Http possui métodos que são utilizados para diferentes finalidades, os principais são o GET e o POST, explicando de forma mínima o GET teria a função de pegar dados do servidor enquanto o POST teria a função de transmitir dados para o servidor.

Como eu faço isso em uma aplicação React

O Código abaixo é uma função javascript que vai receber o nome de uma personagem e vai fazer uma requisição para para a api retornar os personagens que coincidem com aqueles nomes.

const fetchCharacters = async (charactersName) => {
    const response = await fetch(`https://www.breakingbadapi.com/api/characters/?name=${charactersName}`);
    const data = await response.json();
    return data;
  };

Na primeira linha há uma requisição é feita a requisição para o a rota api/characters/ passando o parâmetro name que vai receber o parâmetro da função, a constante response vai receber uma Promise de uma resposta http, para extrair os dados dessa resposta utilizamos na proxima linha o método .json() que também é um Promise só que agora da resposta do servidor com o nome do personagem, apelido...

No caso da minha aplicação essa função é chamada ao enviar do formulário que pergunta o nome do personagem da seguinte forma:

const handleSubmit = async (e) => {
    e.preventDefault();
    const inputValue = e.target[0].value;
    const charachtersData = await fetchCharacters(inputValue);
    setCharacters(charachtersData);
  };
  <form onSubmit={handleSubmit}>

A primeira linha da função handleSubmit vai evitar que a página recarregue por conta do comportamento padrão do elemento form, o inputValue armazena o nome do personagem pesquisado, o charachtersData vai armazenar a resultado da função que foi apresentada anteriormente, e por último a reposta da api é definida como estado pelo setCharacters, agora é só exibir esses dados como queira.

Uma outra forma de fazer essa requisição é quando o componente é montado, digamos que você quer exibir as informações do Walter White enquanto o usuário não escolhe o personagem, você pode ter pensado em fazer da seguinte forma:

const SearchBar = () => {
cosnt [characters, setCharacters] = useState(null)
fetchCharacters('Walter White').then(data => {setCharacters(data)})
  return (
    <form>
      {/*Componentes do formulário*/}
    </form>
  );
};

Se feito dessa forma, você vai ter um problema desse componente ser renderizado infinitamente pois, como ele atualiza o estado do componente, ele força que o componente remonte, e durante o processo de montagem ele vai novamente fazer a requisição e assim por diante...

Para fazer essa requisição enquanto o componente monta é necessário utilizar o hook useEffect, /UTILIZANDO ARRAY DE DEPENDÊNCIAS/

const SearchBar = () => {
cosnt [characters, setCharacters] = useState(null)
useEffect(() => {
  fetchCharacters('Walter White').then(data => {setCharacters(data)},[])
}, [])

  return (
    <form>
      {/*Componentes do formulário*/}
    </form>
  );
};

Dessa forma toda vez que o componente SearchBar for montado a função fetchCharacters vai ser chamada e seu retorno passado para o setCharacters que vai modificar o estado.

Essas são as formas de comunicação http através do React, a partir da montagem do componente ou através de um evento como o enviar do formulário.

Docker basic concepts

Antoniel Magalhães — Thu, 27 Aug 2020 02:58:51 +0000

Docker helps us to manage the services of our applications (Databases or another external service). We can use to create isolated systems in our machine, this means a service doesn't interfere in other services or in our server. The services in our machine are called by images, images are services available to us, containers are instances of these services, are isolated of the rest of our server, containers expose one port to communicate with our machine, we communicate with a container mapping one port of our machine to one port of container, then we have a way to communicate with container.

How to install a new image on docker

Firstly we define which service we use on our application, in this case I will use Postgres. Searching for Postgres Image on google we find the site called by https://hub.docker.com/_/postgres , there you can find a more detailed tutorial, but basically is possible to download a docker image with the following command:

docker run --name database -e POSTGRES_PASSWORD=docker -p 5432:5432 -d postgres

Analizing each pice of the comand above, we got:

docker run ⇒ Create and start a new container with the specify image.
—name database ⇒ Setting a name to our container.
-e POSTGRES_PASSWORD=docker ⇒ Setting environment variables, postgres_password is required for you to use the PostgreSQL image.
-p 5432:5432 ⇒ Mapping [Host port] : [Container port]
-d ⇒ Start container in background
postgres ⇒ Name of the image

After creating our container, how if all is working as we expected? The command docker ps, show all containers running at the moment. If you want to see all containers instead only running you do it using docker ps -a.

References

http://dockerlabs.collabnix.com/docker/cheatsheet/

https://hub.docker.com/_/postgres

How to set up Nodemon & Sucrase

Antoniel Magalhães — Wed, 26 Aug 2020 04:54:34 +0000

What is Sucrase?

Sucrase let us develop Node app in ES6,is an alternative to Babel that allows super-fast development builds. If it fits your use case, hopefully, Sucrase can speed up your development experience!

What is Nodemon?

Nodemon is a tool that helps develop node.js based applications by automatically restarting the node application when file changes in the directory are detected.

Getting Start

First you need to install the packages as development dependencies,

yarn add --dev sucrase 
yarn add --dev nodemon
# Or 
npm install --save-dev sucrase
npm install --save-dev nodemon

After setting the packages as project dependencies, if we try to use the features of Sucrase like this:

node index.js
#Or
nodemon index.js

You will encounter an error because to compile with sucrase, is necessary use sucrase-node instead node, on use nodemon node is called every time some file change in a directory, so how we set to nodemon use sucrase-node instead node?

Nodemon + Sucrase

To set Nodemon to use sucrase we need to create a file nodemon.json in our '/' project, with the following code:

{
  "execMap":{
    "js": "node -r sucrase/register"
  }
}

Once we create this file every time nodemon executes a js file, it will be compiled by sucrase before run the code.

References

https://www.npmjs.com/package/sucrase

https://www.npmjs.com/package/nodemon

Tipos de parâmetros em requisições em http

Antoniel Magalhães — Thu, 20 Aug 2020 01:20:42 +0000

Existem 3 tipos de parâmetros

Query params

São os parâmetros de consulta (query parms) aparecem da seguinte forma: dominio.com/?cidade=salvador.

Esse parâmetros pode ser acessados por:

 app.get('/', (req, res) => {
  const cidade = req.query.cidade
  return res.json(cidade)
})
// Retorna: "salvador"

Route params

Os parâmetros de rota (routes params) aparecem da seguinte forma: dominio.com/usuario/22

Esse parâmetros pode ser acessados por:

 app.get('/usuario/:id', (req, res) => {
  const id = req.parms.id
  return res.json(id)
})
// Retorna: "salvador"

Request body

Diferente dos parâmetros anteriores, o body mão fica visível na url, os dados são transmitidos através do método POST.

Esse parâmetros pode ser acessados por:

const users = ['Usiario0', 'Usuario1', 'Usuario2'] 
app.get('/usuario/', (req, res) => {
  const id = req.body;
  return res.json(users[id])
})
// Retorna: "salvador"

Primeiros passos com TypeScript

Antoniel Magalhães — Thu, 20 Aug 2020 01:07:43 +0000

O que é TypeScript

O TypeScript não é uma nova linguagem, ele pode ser definido como um superset do javascript, ou seja um javascript "melhorado", isso significa que os códigos que são válidos em javascript também são válidos em typescript, TypeScript possui funcionalidades/features adicionais que o js tradicional não traz suporte ainda. Os browsers também não compreendem o typescript, portanto é necessário um transpilador entre ele e o browser. Esse transpilador vai re-escrever o código de forma que os browsers consigam compreender.

TypeScript features:

Tipagem forte

Quando definimos uma variável precisamos especificar qual o seu tipo, há casos que o tipo é identificado sem a necessariamente ser declarado. Utilizar essa funcionalidade torna o código mais previsível e mais fácil de encontrar bugs caso algo dê errado.

Erros em tempo de compilação

Isso permite que seja possível visualizar os erros em tempo de compilação e não somente em tempo de execução, diante disso é possível fixar esses erros antes de iniciar o programa.

Great tooling

Isso permite que a intellisense dos editores de texto consiga prever com maior facilidade os tipos das variáveis que estão sendo trabalhadas.

Getting Start

Inicialmente é necessário instalar o typescript globalmente em nossa máquina, utilizando o gerenciador de pacotes da sua preferência, yarn ou npm.

// Instalando typescript
ts|⇒ yarn add typescript
// Verificando versão
ts|⇒ tsc -v
Version 3.9.5
// Criando o arquivo em que vamos trabalhar
ts|⇒ touch main.ts

Tipos em TypeScript

Declarando tipos

Na maioria das vezes o próprio typescript consegue inferir qual o tipo de cada variável, apenas em momentos específicos os tipos necessitam ser explicitamente declarados. Os diferentes tipos em Ts são:

let a: any;
let a: number;
let a: boolean;
let a: string;
let a: number[] = [1, 2, 3];
let a: any[]= ['A', 1, true, false];

Type Assertions

Para variáveis iniciadas com o valor any, o ts não reconhece qual seus métodos os type assertions são formas de informar, de informar quais o tipo daquela variável após sua inicialização. Type Assertion é unicamente uma forma de dizer ao compilador ts qual a o tipo daquela variável e dessa forma podermos acessa a intellisense.

let message;
let message = "abc" 
let alternativeWay = (message as string).endsWith('c')
let endsWithC = (<string>message).endsWith('c')

Custom types in TypeScript

Nesse caso em específico nossa função tem apenas dois parâmetros mas existem situações em que trabalhando com situações mais complexas é possível ter diversos parâmetros, nessas situações é usual agrupar todos esses parâmetro em um único parâmetro como no parâmetro a seguir.

/*Situação problemática*/
let drawPoint = (point) => {
    //Suponhamos um algorítimo que vai desenhar na tela
    //e precisa das cordenadas x e y
    //Acessadas por point.x, point.y
}

drawPoint({
    x: 1,
    y: 2
})

Na situação acima caso o objeto que seja passado não tenha as chaves e valores esperados pela função há grandes chances de que esse programa quebre durante o tempo de execução. Uma forma de prevenir essa situação é passar a custom type para esse parâmetro da seguinte forma.

/*Situação resolvida*/
/*Inline Notation*/
let drawPoint = (point: {x: number, y:number}) => {
    //...
}

/*Situação resolvida*/
/*Utilizando Interfaces*/
interface Point = {
    x: number,
    y: number,  
}
let drawPoint = (point: Point) => {
    //...
}

Acima temos as duas abordagens de custom types, inline Notation e utilizando interfaces, utilizar interfaces leva certa vantagem sobre o inline pois tem uma abordagem mais limpa, em caso de muitos parâmetros a primeira pode se tornar confusa, além do fato de que as interfaces podem ser reutilizadas em diversos lugares.

DEV Community: Antoniel Magalhães

Seu time não merece revisar seu PR

O problema

Stacked PRs

Um guia prático

Usando IA para criar a stack

Como validar que nada se perdeu

A verificação que importa

Automatizando a abertura dos PRs com gh CLI

O fluxo com gh

A lição

Stop F*cking Your Team With Giant PRs

The problem

Stacked PRs

A practical guide

Using AI to stack PRs

How to validate nothing was lost

The check that matters

Automating PR creation with gh CLI

The gh flow

The lesson

Meu Processo de Agentic Engineering: Do Vibe Code ao BDD

Introdução

Vibe Code vs Agent Engineering

Vibe coding

Agentic engineering

Explorando novos padrões de agentic engineering

TDD

Antes: Just Go

Depois: BDD

BDD

/tony-bdd

/tony-bdd-test

/tony-workflow

Specs First vs BDD

Conclusão

Resultados

Referências

My Agentic Engineering Process: From Vibe Code to BDD

Introduction

Vibe Code vs Agent Engineering

Vibe coding

Agentic engineering

Exploring new agentic engineering patterns

TDD

Before: Just Go

After: BDD

BDD

/tony-bdd

/tony-bdd-test

/tony-workflow

Specs First vs BDD

Conclusion

Results

References

Entendendo useState e useReducer

Introdução

useState

useReducer

Exemplos

useState

useReducer

References

Consumindo uma API no React

Contexto

Como ?

Como eu faço isso em uma aplicação React

Docker basic concepts

How to install a new image on docker

References

How to set up Nodemon & Sucrase

What is Sucrase?

What is Nodemon?

Getting Start

Nodemon + Sucrase

References

Tipos de parâmetros em requisições em http

Primeiros passos com TypeScript

O que é TypeScript

TypeScript features:

O fluxo com `gh`

The `gh` flow