O desafio da semana será implementar um checkout típico, partindo de um modelo semi estático pré componentizado utilizando MUI. O código de base pode ser rodado aqui e baixado a partir daqui.
- Precisamos ter instalado pelo menos o Node 16.x.x
✅ Pode
- Não há nenhuma restrição sobre alterar os arquivos de base, desde que cumpram o que está sendo explicitamente pedido nas tarefas.
- Adicionar validações de formato não é parte do desafio, mas seria muito interessante de ver. Pode tentar ao final depois de concluir todas as tarefas.
🚫 Não pode
- Instalar libs além das que forem pedidas explicitamente (a Tarefa 1 cobre isso)
Considerando o desafio da semana passada.
- Para quem tem o desafio da semana passada pronto, utilize o código do seu próprio desafio!
- Copie o diretório do checkout modelo para dentro de um diretório
Checkout
no seu diretório de componentes.- Delete os arquivos que não serão utilizados: qualquer outro que não termine com *.js
- Crie um barrel file dentro da nova pasta
Checkout
- A barra de topo onde aparece
Company name
pode ser completamente removida e não tem utilidade para nós. Apenas a caixa onde apareceCheckout
precisa aparecer (com o mesmo alinhamento atual).- Caso opte por não remover o topo, ele deve no mínimo ser removido do componente
Checkout
e levado para oApp
, o textoCompany name
também deve ser mudado para um nome de sua preferência.
- Caso opte por não remover o topo, ele deve no mínimo ser removido do componente
- Os mesmos critérios acima se aplicam no rodapé onde está escrito
Copyright © Your Website 2022
. - Para quem tem o desafio da semana passada acrescente uma terceira tela onde será renderizado o
Checkout
. Essa terceira tela deve ser disponível ao clicar em algum link ou botão do carrinho.
- Crie uma app nova usando
create-react-app
e renderize oCheckout
direto noApp
. - O teste de
App.test.js
basta procurar pela palavraCheckout
- Providencie o teste da semana passada, vai ser preciso na última task. Está permitido usar código de outro trainee que tenha o desafio da semana passada completo.
Segue uma sugestão de estrutura dos testes em português (os testes devem ser descritos sempre em inglês!)
App.test.js
(ou componente do carrinho que contém o link/botão que leva ao checkout)- Ao clicar no botão ou link indicado
- eu devo ver
Checkout
- eu devo ver
- Ao clicar no botão ou link indicado
Checkout.test.js
- Quando renderizado
- eu devo ver
Checkout
- eu devo ver
Shipping Address
- ao clicar em
Next
- eu devo ver
Payment method
- eu devo ver
- ao clicar em
Next
duas vezes- eu devo ver
Order summary
- eu devo ver
- ao clicar em
- eu devo ver
- Quando renderizado
💡 Durante o processo haverão mensagens de erro devido a libs utilizadas no Checkout
que copiamos. As 3 libs utilizadas DEVEM ser adicionadas como dependência para que tudo funcione corretamente.
Os campos State/Province/Region
e Country
precisam ser dinâmicos e populados a partir deste JSON.
- MUDE A ordem dos campos de endereço:
- penultima linha:
Zip/Postal Code
,City
- última linha -
State/Province/Region
,Country
Country
,State/Province/Region
- penultima linha:
- Você DEVE utilizar o
select
fornecido pelo MUI nos camposState/Province/Region
eCountry
. Aqui está o link da documentação dele. - O JSON fornecido não pode ser alterado e deve ser copiado intácto para dentro do projeto no diretório que parecer mais conveniente.
- O campo
Country
deve ser populado uma vez só de maneira estática com base no JSON fornecido. - O campo
State/Province/Region
deve ser repopulado sempre queCountry
mudar, com base no JSON fornecido. - Ambos os selects devem ser mostrados inicialmente sem nenhum valor pré selecionado.
- O campo
🟢 Os testes do componente contendo estes selects precisam descrever esse comportamento.
Ao chegar na tela de review todos os campos digitados precisam ser mostrados no formato de exemplo que hoje está estático.
- Os botões
Next
precisam ser habilitados somente quando os campos definidios comorequired
são preenchidos.- Mostrar a mensagem da validação é opcional para este desafio.
- Os botões
Back
levam para a tela anterior, estas devem manter o formulário com os valores guardados. - Na tela de review o cartão de crédito deve ser mostrado no formato: xxxx-xxxx-xxxx-1234
🟢 Os testes de Checkout.test.js
devem ser atualizados para incluir essas funcionalidades. Um teste somente da tela de Review demonstrando a impressão correta dos valores recebidos também é interessante.
- Todo do formulário deve ser navegável com tab de forma lógica
- <enter> DEVE avançar para a próxima tela quando o foco está em um dos campos e os campos apresentados na tela estão todos válidos (estamos validando somente a presença dos requireds). OBS.: em um form comum, o evento submit ocorre tanto apertando o botão
type="submit"
quanto a tecla <enter>, se possível aproveite esse comportamento padrão.
Order Summary
deve mostrar a lista dos produtos adicionados (do desafio da semana passada). ⌛ Para quem não conseguiu fazer o desafio da semana passada, vai precisar fazer um carrinho de compras mínimo para completar essa última etapa. Está permitido usar código de outro trainee que tenha o desafio da semana passada completo.
🟢 Os testes de App.test.js
precisam ser atualizados para descrever esse comportamento.
- Todos os PRs precisam ter uma descrição adequada descrevendo de forma clara, breve porém completa sobre o conteúdo e a motivação do PR (objetivos que o PR tenta alcançar). Estas descrições precisam estar necessariamente de acordo com este documento, linkando ou não.
- Um PR pode resolver várias tasks, desde que esteja descrito corretamente o conteúdo e motivação.
- O título do PR não pode ser apenas task 1, task 2..., é essencial resumir o que o PR faz em uma única frase.
Task 1 -
pode ser um prefixo para o título do PR, porém o título é mais importante que o prefixo. - Adição do mesmo código em diferentes PRs dificulta a revisão e pode causar conflitos denescessários. Caso um PR dependa de outro, aponte-o para o PR dependente ou indique isso de alguma forma na descrição.
- Acrescente screenshots em cada PR. Alguns screenshots precisam ser descritos corretamente para que se tenha um entendimento do que está sendo mostrado. screenshots animados frequentemente dispensam descrição!
- Em caso de algum revisor contradizer qualquer critério deste documento. Copie e cole o trecho do critério em questão seguido do link para este documento.
- Em caso de algum revisor solicitar refatoração no código de base do
Checkout
(legado), está só será obrigatória caso esteja diretamente alinhada com o propósito da task. Caso contrário, é inteiramente opicional e o revisor deve ser informado quanto a isso.