Skip to content
This repository has been archived by the owner on Mar 1, 2023. It is now read-only.

Latest commit

 

History

History
93 lines (73 loc) · 4.57 KB

DESAFIO.md

File metadata and controls

93 lines (73 loc) · 4.57 KB

Telas de busca e cadastro de produtos

A super-big-corp tem uma nova solução chamada varejim, que resolve o problema do pequeno varejista. Para tanto, esse software tem uma coleção de endpoints REST que devem ser consumidos pro interfaces web modernas.

Implemente uma pequena SPA (Single Page Application) contendo a tela de listagem e a tela de cadastro/edição de produtos, onde as telas deverão consumir os endpoints REST oferecidos pelo projeto backend node presente neste repositório.

Um README.md deve ser adicionado explicando os passos necessários para construir e rodar o projeto frontend.

Requisitos obrigatórios

  • A tela de listagem é a tela inicial.
  • Deve ter uma tela de listagem com pelo menos uma tabela e um campo de filtro
  • A tela de listagem deve oferecer paginação.
  • A busca deve ser intuitiva e buscar por código quando o usuário fornecer números e por descrição se houver texto.
  • Ao selecionar uma linha da tabela, deve navegar para a tela de cadastro/edição.
  • A opção 'excluir' deve ser oferecida tanto na tela de edição quanto na tela de listagem.
  • Na tela de cadastro/edição, campos obrigatórios devem ser validados.
  • Este repositório é um monorepo/multiproject. o serviço a ser consumido encontra-se em varejim-produto-service. A implementação da solução frontend deve ser feita em varejim-produto-web..
  • O README.md do projeto frontend deve detalhar todos os passos e requisitos para executar o frontend e consumir o backend.
  • É muito importante que o projeto possa ser executado em ambiente linux, macos ou windows. ao menos uma plataforma deve ser contemplada. indicar claramente onde os testes e desenvolvimento ocorreram no README.md.
  • Usar vue-router para implementar a SPA.

Pontuação bônus

  • Demonstrar conhecimento de ES6
  • Usar vue test utils
  • Usar alguma ferramenta capaz de gerar relatório de cobertura de testes.
  • Rodar em mais de uma plataforma (Linux, MacOS, Windows ou outro, x86 ou arm).
  • Boas práticas de estilo e codificação.
  • ESLint/Prettier.
  • Babel.
  • Dot env flow para variáveis de ambiente para a construção do projeto, como sugestão: pode se usar para recuperar a url do endpoint do serviço.
  • Usar Vuex pra preservar o estado dos filtros da tela de listagem.
  • Criar e documentar alguma implementação extra não solicitada aqui mas que contribua de alguma forma para a solução.

O que será julgado

  • A justa e correta realização dos requisitos obrigatórios.
  • A forma que as pontuações bônus foram implementadas, se fazem sentido pelo menos enquanto exemplo de uso correto da tecnologia.
  • A qualidade do código.
  • A interpretação feita dos requisitos e dos bônus. Mesmo objetivos, são passíveis de interpretação e, caso pareça necessário, detalhar no README.md as motivações por trás da implementação feita.
  • A simplicidade da solução.
  • A forma que as pontuações bônus foram realizadas, se alguma for feita.
  • A qualidade do README.md enquanto informativo de construção e execução do projeto.
  • Caso executada a última pontuação bônus, até que ponto a tecnologia aplicada é de fato interessante benéfica e quão boa é a apresentação e defesa técnica da mesma no README.md do projeto web.

Prazo

O esforço imaginado para realizar este desafio é de 4 dias (i.e. 32 horas).

Recomenda-se uma data de início contemplando um fim de semana caso exista um trabalho regular semanal a ser realizado, pois assim é possível solicitar mais um ou dois dias compensando o esforço a ser feito fora do horário de expediente.

É possível terminar antes deste prazo, e, se os requisitos obrigatórios forem cumpridos, o bônus de tempo é apreciado.

Caso o avaliador observe que é preciso algum ajuste no desafio, um tempo adicional de esforço poderá ser oferecido. Mais uma vez, negociar como será a janela de tempo.

Forma de entrega

Uma vez implementada a solução, indicar o link do repositório para o avaliador apontado pela Casa Magalhães e aguardar feedback.

Sobre o feedback

É importante que o feedback seja bastante completo para que nenhum esforço seja em vão, já que o teste se trata de uma pequena aplicação e leva um pouco mais de tempo. Caso sinta que o feedback fornecido não foi suficiente, sinta-se livre para solicitar mais informações.

Dúvidas

A qualquer momento entre em contato com o avaliador técnico indicado pela CM pra sanar dúvidas. Comunicação é essencial.