Ao iniciar este projeto, você concorda com as diretrizes do Código de Ética e Conduta e do Manual da Pessoa Estudante da Trybe.
Você já usa o GitHub diariamente para desenvolver os exercícios, certo? Agora, para desenvolver os projetos, você deverá seguir as instruções a seguir. Fique atento a cada passo, e se tiver qualquer dúvida, nos envie por Slack! #vqv 🚀
Aqui você vai encontrar os detalhes de como estruturar o desenvolvimento do seu projeto a partir desse repositório, utilizando uma branch específica e um Pull Request para colocar seus códigos.
Nesse projeto, você será capaz de:
-
Criar um store Redux em aplicações React
-
Criar reducers no Redux em aplicações React
-
Criar actions no Redux em aplicações React
-
Criar dispatchers no Redux em aplicações React
-
Conectar Redux aos componentes React
-
Criar actions assíncronas na sua aplicação React que faz uso de Redux.
- O que deverá ser desenvolvido
- Data de entrega
- Como desenvolver
- Requisitos do projeto
- Lista de requisitos
- Tela de início
- Tela de jogo
- 4 - Crie um header que deve conter as informações da pessoa jogadora
- 5 - Crie a página de jogo que deve conter as informações relacionadas à pergunta
- 6 - Desenvolva o jogo onde só deve ser possível escolher uma resposta correta por pergunta
- 7 - Desenvolva o estilo que, ao clicar em uma resposta, a correta deve ficar verde e as incorretas, vermelhas
- 8 - Desenvolva um timer onde a pessoa que joga tem 30 segundos para responder
- 9 - Crie o placar os as seguintes características
- 10 - Crie um botão de próxima que apareça após a resposta ser dada
- 11 - Desenvolva o jogo de forma que a pessoa que joga deve responder 5 perguntas no total
- Tela de feedback
- 12 - Desenvolva o header de feedback, que deve conter as informações da pessoa jogadora
- 13 - Crie a mensagem de feedback para ser exibida à pessoa usuária
- 14 - Exiba as informações relacionadas aos resultados obtidos para a pessoa usuária
- 15 - Crie a opção para a pessoa jogadora poder jogar novamente
- 16 - Crie a opção para a pessoa jogadora poder visualizar a tela de ranking
- Tela de ranking
- Extra não avaliativo: tela de configurações
- Instruções para entregar seu projeto
- Avisos finais
Você deverá desenvolver um jogo de perguntas e respostas baseado no jogo Trivia (tipo um show do milhão americano rs) utilizando React e Redux, desenvolvendo em grupo suas funcionalidades de acordo com as demanas definidas em um quadro Kanban. Para viver um cenário mais próximo do mercado de trabalho, você deve fazer uma cópia desse quadro para utilizar com seu grupo. A partir dessas demandas, teremos uma aplicação onde a pessoa usuária poderá:
- Logar no jogo e, se o email tiver cadastro no site Gravatar, ter sua foto associada ao perfil de usuária.
- Acessar a página referente ao jogo, onde se deverá escolher uma das respostas disponíveis para cada uma das perguntas apresentadas. A resposta deve ser marcada antes do contador de tempo chegar a zero, caso contrário a resposta deverá ser considerada errada.
- Ser redirecionada, após 5 perguntas respondidas, para a tela de score, onde o texto mostrado depende do número de acertos.
- Visualizar a página de ranking, se quiser, ao final de cada jogo.
- Configurar algumas opções para o jogo em uma tela de configuração acessível a partir do cabeçalho do app.
Você pode acessar um protótipo completo da interface desejada para o projeto neste link.
Sinta-se livre para alterar a UI. Só respeite as restrições de cada requisito - elas serão usados na correção.
-
Projeto em grupo.
-
Serão cinco dias de projeto.
-
O projeto tem até a seguinte data:
dd/mm/yyyy - 14:00h
para ter entregue a avaliação final.
Este repositório já conta com uma main-group
para cada grupo, identificada como main-group-1
para o grupo 1, main-group-2
para o grupo 2, e assim por diante. Para desenvolver, você sempre deve:
- Criar sua branch de desenvolvimento a partir da sua branch main. Para isso, clone este repositório, faça o
git checkout main-group-XX && git pull
e em seguida ogit checkout -b main-group-XX-minha-feature
. - Para criar uma Pull Request para fazer Code Review, entitule-a
[GRUPO XX] Meu título
e sempre aponte a Pull Request da sua branch para a branchmain-group-XX
do seu grupo, como no exemplo abaixo:
- Quando várias pessoas desenvolvem para um mesmo projeto podem ocorrer conflitos de merge que precisarão ser resolvidos. Prestem atenção a isso!
⚠ ATENÇÃO! É POSSÍVEL COMMITAR, POR ENGANO, NA BRANCH DE OUTRO GRUPO, ENTÃO TOME MUITO CUIDADO ⚠
- Clone o repositório
git clone [email protected]:tryber/sd-06-project-trivia-react-redux.git
.- Entre na pasta do repositório que você acabou de clonar:
cd sd-06-project-trivia-react-redux
- Vá para a branch do seu grupo, com
git checkout main-group-XX && git pull
, ondeXX
é o número do seu grupo. Exemplos:main-group-1
,main-group-22
.
- Instale as dependências e inicialize o projeto
- Instale as dependências:
npm install
- Inicialize o projeto:
npm start
(uma nova página deve abrir no seu navegador com um texto simples)
- Faça alterações separadas por novas branchs criadas a partir da branch
main-group-XX
, criando uma nova branch para cada demanda
- Verifique que você está na branch
main-group-XX
- Exemplo:
git branch
- Exemplo:
- Se não estiver, mude para a branch
main-group-XX
- Exemplo:
git checkout main-group-XX && git pull
- Exemplo:
- Agora, crie uma branch para a demanda que você vai desenvolver do seu projeto
- Você deve criar uma branch com uma breve descrição da demanda a ser desenvolvida
- Exemplo:
git checkout -b main-group-XX-cria-campo-de-input
- Adicione as mudanças ao stage do Git e faça um
commit
- Verifique que as mudanças ainda não estão no stage
- Exemplo:
git status
(devem aparecer listadas as novas alterações em vermelho)
- Exemplo:
- Adicione o arquivo alterado ao stage do Git
- Exemplo:
git add .
(adicionando todas as mudanças - que estavam em vermelho - ao stage do Git)git status
(devem aparecer listadas as novas alterações em verde)
- Exemplo:
- Faça seus
commit
- Exemplo:
git commit -m 'cria componente de input
git status
(deve aparecer uma mensagem tipo nothing to commit )
- Exemplo:
- Adicione a sua branch com o novo
commit
ao repositório remoto
- Usando o exemplo anterior:
git push -u origin main-group-XX-cria-campo-de-input
- Crie um novo
Pull Request
(PR)
- Vá até a página de Pull Requests do repositório no GitHub
- Clique no botão verde "New pull request"
- Clique na caixa de seleção "Compare" e escolha a branch do grupo,
main-group-XX
, e a sua branch com atenção - Coloque um título para a sua Pull Request
- Exemplo: "[GRUPO XX] Cria tela de busca"
- Clique no botão verde "Create pull request"
- Adicione uma descrição para o Pull Request e clique no botão verde "Create pull request"
- Não se preocupe em preencher mais nada por enquanto!
- Volte até a página de Pull Requests do repositório e confira que o seu Pull Request está criado
- Assim que aprovado por pelo menos duas pessoas do seu grupo e o Linter estiver adereçado, acesse SEU Pull Request e clique no botão "Merge pull request"
Para o bom andamento deste projeto disponibilizamos, além do README a seguir, um quadro Kanban com as demandas a realizar para o projeto ser concluído com sucesso. Confira o Slack para saber como acessar o quadro! É de suma importância que o grupo se organize utilizando o quadro para maior eficiência e para que se minimizem os conflitos que a união de vários códigos trará.
Além disso, você verá que os requisitos do projeto tem, além das observações técnicas e do que será validado, descrições tais quais se veriam em um projeto real. É muito importante ser capaz de ler descrições como essa e transformá-las em produtos ou, se houver dúvida, saber tirar tais dúvidas! Seguimos à disposição no Slack para isso.
Este repositório já contem um template com um App React criado, configurado e com os testes automatizados que fazem parte da correção. Ele também conta com uma branch main-group para cada grupo, identificada como main-group-1
para o grupo 1, main-group-2
para o grupo 2 e assim por diante.
Para garantir a qualidade do seu código de forma a tê-lo mais legível, de mais fácil manutenção e seguindo as boas práticas de desenvolvimento nós utilizamos neste projeto o linter ESLint
. Para rodar o linter localmente no seu projeto, execute o comando abaixo:
npm run lint
⚠ PULL REQUESTS COM ISSUES DE LINTER NÃO SERÃO AVALIADAS. ATENTE-SE PARA RESOLVÊ-LAS ANTES DE FINALIZAR O DESENVOLVIMENTO! ⚠
Os testes deste projeto foram feitos utilizando o Cypress. É utilizada nos testes a resolução 1366 x 768
(1366 pixels de largura por 768 pixels de altura) para testes de layout. Logo, recomenda-se desenvolver seu projeto usando a mesma resolução, via instalação deste plugin do Chrome
para facilitar a configuração dessa resolução, por exemplo.
Para o projeto ser validado, todos os testes de comportamento devem passar. É possível testar isso local rodando npm run cy
. Esse comando roda a suite de testes do Cypress que valida se o fluxo geral e os requisitos funcionais estão funcionando como deveriam. Você pode também executar o comando npm run cy:open
para ter um resultado visual dos testes executados.
Esses testes não consideram o layout de maneira geral, mas sim os atributos e informações corretas, então preste atenção nisso! Os testes te darão uma mensagem de erro caso não estejam passando (seja qual for o motivo). 😉
Atenção: Sua aplicação deve estar rodando para o Cypress no terminal poder testar.
A API do Trivia é bem simples. Temos 2 endpoints que vamos precisar utilizar para esse exercício.
- Pegar o token de sessão da pessoa que está jogando
- Pegar perguntas e respostas
Primeiro, é necessário fazer um GET request para:
https://opentdb.com/api_token.php?command=request
Esse endpoint te retornará o token que vai ser utilizado nas requisições seguintes. A resposta dele será:
{
"response_code":0,
"response_message":"Token Generated Successfully!",
"token":"f00cb469ce38726ee00a7c6836761b0a4fb808181a125dcde6d50a9f3c9127b6"
}
Paga pegar as perguntas, você deve realizar um GET request para o seguinte endpoint:
https://opentdb.com/api.php?amount=${quantidade-de-perguntas-retornadas}&token=${seu-token-aqui}
// Recomendação
https://opentdb.com/api.php?amount=5&token=${seu-token-aqui}
Recomendamos pedir 5 perguntas de uma vez e controlar a disposição delas no código. Essa API te retorna as perguntas no seguinte formato:
// Pergunta de múltipla escolha
{
"response_code":0,
"results":[
{
"category":"Entertainment: Video Games",
"type":"multiple",
"difficulty":"easy",
"question":"What is the first weapon you acquire in Half-Life?",
"correct_answer":"A crowbar",
"incorrect_answers":[
"A pistol",
"The H.E.V suit",
"Your fists"
]
}
]
}
// Pergunta de verdadeiro ou falso
{
"response_code":0,
"results":[
{
"category":"Entertainment: Video Games",
"type":"boolean",
"difficulty":"hard",
"question":"TF2: Sentry rocket damage falloff is calculated based on the distance between the sentry and the enemy, not the engineer and the enemy",
"correct_answer":"False",
"incorrect_answers":[
"True"
]
}
]
}
O token expira em 6 horas e te retornará um response_code: 3
caso esteja expirado. Atenção para que seu código contemple isso! Caso o token seja inválido, essa será a resposta da API:
{
"response_code":3,
"results":[]
}
O Gravatar é um serviço que permite deixar o avatar global a partir do email cadastrado, ele mostra sua foto cadastrada em qualquer site vinculado. Na tela de Inicio, a pessoa que joga pode colocar um e-mail que deve fazer uma consulta a API do Gravatar.
A Implementação é feita baseada no e-mail. Esse email deve ser transformado em uma hash MD5
(https://br.gravatar.com/site/implement/hash/). Para gerar tal hash, recomendamos utilizar o CryptoJs.
Por exemplo:
-
Garantida a instalação do CryptoJS no projeto, importe o MD5:
import md5 from 'crypto-js/md5';
-
Converta o email do usuário:
md5(emailDoUsuário)
Após a geração da hash, basta adicionar o valor gerado no final da URL:
// Formato de URL necessário:
https://www.gravatar.com/avatar/${hash-gerada}
// Exemplo de URL com hash de uma pessoa
https://www.gravatar.com/avatar/205e460b479e2e5b48aec07710c08d50
// Exemplo de imagem exibida com a URL
<img src="https://www.gravatar.com/avatar/205e460b479e2e5b48aec07710c08d50" />
Os requisitos são organizados por telas e grupos de prioridade. Demandas de um grupo de prioridade podem ser realizadas em paralelo, e são pré-requisito para as demandas do grupo de prioridade seguinte. Por exemplo:
- A tela de login possui como prioridade 0 a criação do input de nome e email, mas só é possível fazer a ação de habilitar/desabilitar botão e salvar o token do usuário (prioridade 1), quando os inputs estiverem prontos
Se você não seguir a ordem de prioridades terá que lidar com mais conflitos de merge e demandas concorrentes, onde o avanço de uma depende, na maioria das vezes, do avanço de outra para poder acontecer. Ainda que siga a ordem de prioridade, no entanto, conflitos podem ocorrer a depender de como for feita a implementação do projeto, então é importante que o grupo faça esse alinhamento constantemente!
ATENÇÃO! O avaliador testa a aplicação de maneira integrada. Ou seja: a tela de jogo só é aprovada quando a tela de login estiver pronta; As telas de ranking e feedback só serão aprovadas depois que as telas de login e jogo estiverem prontas. É possível fazer as telas de jogo, ranking e feedback em paralelo, se a estrutura dos componentes for combinada pelo grupo! Faz parte do desafio o desenvolvimento da aplicação sem o "acompanhamento" constante do avaliador.
Recomendamos, além disso, que os requisitos de uma mesma tela sejam feitos em sequência ou paralelamente por pessoas se comunicando bastante, para não haver conflitos. Embora requisitos de uma mesma tela com prioridades iguais possam ser feitos em paralelo, isso exigirá organização por parte das pessoas dividindo a tarefa para não haver conflitos.
Algumas coisas devem seguir um padrão pré-estabelecido para que os teste de correção funcionem corretamente.
Player
No localStorage
do navegador:
- A chave
state
deve conter a seguinte estrutura:
player: {
name,
assertions,
score,
gravatarEmail
}
name
é o nome da pessoa que joga
assertions
é o número de acertos
score
é a pontuação
gravatarEmail
é o email da pessoa que joga
- A chave
ranking
deve conter a seguinte estrutura:
[
{ name: nome-da-pessoa, score: 10, picture: url-da-foto-no-gravatar }
]
- A chave
token
deve conter o valor do token recebido na API do Trivia.
Nesse projeto, a pessoa que joga deve conseguir completar o jogo e conseguir ver seu placar depois de responder todas as 5 perguntas, além de acessar a tela de configurações e de ranking. Lembrem-se de utilizar os conhecimentos adquiridos ao longo dos últimos projetos nas ferramentas do React como o Router, Link, Redux e testes para ajudá-los a completar os requisitos.
PRIORIDADE 0 - Criar a tela de login contendo as informações de nome e email, onde a pessoa que joga deve conseguir escrever seu nome e email nos inputs e o botão de jogar deve estar desabilitado caso não tenha alguma dessas informações.
Recomendamos que o Redux e o Router sejam configurados nesse requisito, para que os demais possam ser feitos paralelamente!
Observações técnicas
- A pessoa que joga deve conseguir escrever seu nome no input de texto
- A pessoa que joga deve conseguir escrever seu email no input de email
- O botão "Jogar" deve ser desabilitado caso email e/ou nome não estejam preenchidos
- O campo de texto para o nome deve possuir o atributo
data-testid
com o valorinput-player-name
- O campo de texto para o email deve possuir o atributo
data-testid
com o valorinput-gravatar-email
- O botão "Jogar" que leva a pessoa ao jogo deve possuir o atributo
data-testid
com o valorbtn-play
O que será avaliado
- Escreve o nome da pessoa jogadora
- Escreve o email da pessoa jogadora
- Botão Jogar desabilitado quando pessoa jogadora não preencher nenhum campo
- Botão Jogar desabilitado quando pessoa jogadora escrever apenas o nome
- Botão Jogar desabilitado quando pessoa jogadora escrever apenas o email
- Botão Jogar habilitado quando pessoa jogadora preencher os campos de nome e email
PRIORIDADE 1 - O botão "Jogar" deve fazer requisição para a API para obter o token e redirecionar a pessoa para tela de jogo
Observações técnicas
- Após clicar no botão "Jogar", a pessoa deve ser redirecionada para a tela do jogo
- Ao clicar no botão "Jogar", um requisição para a API do Trivia deve ser feita para obter o token de jogador
- O token deve ser armazenado na aplicação e enviado em todas as requisições seguintes.
- Salve no
LocalStorage
o token recebido utilizando a chavetoken
O que será avaliado
- Inicia jogo salvando um token de jogador
PRIORIDADE 1 - A tela inicial deve conter um botão que leve para a configuração do jogo
Observações técnicas
- O botão que leva a pessoa a tela de configurações deve possuir o atributo
data-testid
com o valorbtn-settings
- A tela de configurações deve possuir um título com o atributo
data-testid
contendo o valorsettings-title
O que será avaliado
- O botão deve existir na página
- A tela de configurações deve possuir um título
PRIORIDADE 1 - O header deve conter as informações sobre a pessoa jogadora, como a imagem do Gravatar, o nome e o placar
Observações técnicas
- A imagem do perfil vinda do Gravatar em um elemento que deve possuir o atributo
data-testid
com o valorheader-profile-picture
- O nome da pessoa em um elemento que deve possuir o atributo
data-testid
com o valorheader-player-name
- O placar zerado em um elemento que deve possuir o atributo
data-testid
com o valorheader-score
O que será avaliado
- A imagem do Gravatar está presente no header
- O nome da pessoa está presente no header
- O placar zerado está presente no header
PRIORIDADE 1 - Deve ser feita a requisição para a API para popular o jogo com as perguntas, categoria e alternativas
Observações técnicas
- A pergunta e suas alternativas de resposta devem ser recebidas da API do Trivia
- A categoria da pergunta (campo category) deve ser exibida em um elemento com o atributo
data-testid
com o valorquestion-category
para a pessoa que está jogando - O texto da pergunta (campo question) deve ser exibido em um elemento com o atributo
data-testid
com o valorquestion-text
para a pessoa que está jogando - O texto com as alternativas devem ser exibidos seguindo as regras abaixo:
- O elemento com a alternativa correta deve possuir o atributo
data-testid
com o valorcorrect-answer
- Os elementos com as alternativas incorretas devem possuir o atributo
data-testid
com o valorwrong-answer-${index}
, com${index}
iniciando com o valor0
- As alternativas devem ser exibidas em ordem aleatória
- Dica: utilize botões (
<button/>
) para as alternativas
- O elemento com a alternativa correta deve possuir o atributo
O que será avaliado
- A categoria da pergunta está presente
- O texto da pergunta está presente
- As alternativas devem estar presentes
PRIORIDADE 2 - A pergunta deve ter apenas uma alternativa correta
Observações técnicas
- Apenas uma alternativa deve ser a correta
O que será avaliado
- A quantidade de respostas corretas deve ser 1
7. DESENVOLVA O ESTILO QUE, AO CLICAR EM UMA RESPOSTA, A CORRETA DEVE FICAR VERDE E AS INCORRETAS, VERMELHAS
PRIORIDADE 2 - Ao responder a pergunta, se a alternativa for correta, deve ficar verde, caso contrário, vermelha
Observações técnicas
- Utilize a propriedade css
border
com o valor3px solid rgb(6, 240, 15)
para a alternativa correta. - Utilize a propriedade css
border
com o valor3px solid rgb(255, 0, 0)
para as alternativas incorretas.
O que será avaliado
- Verifica cor da alternativa correta quando acerta a questão
- Verifica a cor das alternativas incorretas quando acerta a questão
- Verifica cor da alternativa correta quando erra a questão
- Verifica a cor das alternativas incorretas quando erra a questão
PRIORIDADE 3 - A página deve conter um timer que com o tempo máximo de 30 segundos para responder, caso ultrapasse o tempo, a pergunta é considerada errada
Observações técnicas
- Caso a pergunta não seja respondida a tempo, a resposta é considerada como errada
- Respostas incorretas não somam pontos ao placar
- Um temporizador deve aparecer na tela da pessoa, começando de 30 segundos e indo de forma decrescente até zero
- Após o tempo se esgotar, todos os botões das alternativas devem ser desabilitados
Dica: Lembre-se do setTimeout e do setInterval
O que será avaliado
- Aguarda 5 segundos e responde a alternativa correta
- Aguarda mais de 30 segundos para responder
PRIORIDADE 3 - Ao clicar na resposta correta, pontos devem ser somados no placar da pessoa que está jogando
Observações técnicas
- Você deve salvar a pontuação atual no
localStorage
- Leia a seção "Implementações técnicas" para mais detalhes
- Respostas erradas não devem somar ao placar
- A fórmula para cálculo dos pontos por pergunta é:
10 + (timer * dificuldade)
, onde timer é o tempo restante no contador de tempo e dificuldade éhard: 3, medium: 2, easy: 1
, dependendo da pergunta. Exemplo: Se no momento da resposta correta o timer estiver contando 17 segundos, e a dificuldade da pergunta é 2 (média), a pontuação deve ser:10 + (17 * 2) = 44
O que será avaliado
- Soma pontos ao acertar uma questão
- Não soma pontos ao errar uma questão
PRIORIDADE 3 - Deve aparecer um botão de "Próxima" (pergunta) após a resposta ser dada
Observações técnicas
- O botão "Próxima" deve possuir o atributo
data-testid
com o valorbtn-next
- Ao clicar nesse botão, a próxima pergunta deve aparecer na tela
O que será avaliado
- O botão de próxima pergunta não deve ser visível o início do jogo
- Botão de próxima pergunta é visível quando a pergunta é respondida corretamente
- Botão de próxima pergunta é visível quando a pergunta é respondida incorretamente
PRIORIDADE 2 - O jogo deve ser composto por 5 perguntas, onde, a cada nova pergunta, o timer é reiniciado e após respondê-las, a pessoa que joga deve ser redirecionada para a tela de feedback
Observações técnicas
- A cada nova pergunta o temporizador deve ser reiniciado para 30 segundos
- Após a quinta pergunta, o botão "Próxima" deve redirecionar a pessoa para a tela de Feedback
- Para perguntas com type:"boolean", mostrar somente 2 campos (um para cada resposta possível)
- Para perguntas com type:"multiple", mostrar a quantidade necessária de campos (um para cada resposta possível)
O que será avaliado
- Acerta todas as perguntas
- Erra todas as perguntas
- Redireciona para a tela de feedback após a quinta pergunta
PRIORIDADE 0 - A tela de feedback deve conter as informações da pessoa que joga, incluindo o placar com o valor referente ao desempenho no jogo
Observações técnicas
- A imagem do perfil vinda do Gravatar em um elemento que deve possuir o atributo
data-testid
com o valorheader-profile-picture
- O nome da pessoa em um elemento que deve possuir o atributo
data-testid
com o valorheader-player-name
- O placar com o valor atual em um elemento que deve possuir o atributo
data-testid
com o valorheader-score
O que será avaliado
- A imagem do Gravatar está presente no header
- O nome da pessoa está presente no header
- O placar com o valor atual está presente no header
PRIORIDADE 1 - A tela de feedback deve exibir uma mensagem relacionada ao desempenho da pessoa que jogou
Observações técnicas
- A mensagem deve ser "Podia ser melhor..." caso a pessoa acerte menos de 3 perguntas
- A mensagem deve ser "Mandou bem!" caso a pessoa acerte 3 perguntas ou mais
- O elemento da mensagem de feedback deve possuir o atributo
data-testid
com o valorfeedback-text
O que será avaliado
- Acertou menos de 3 perguntas
- Acertou 3 perguntas
- Acertou mais de 3 perguntas
PRIORIDADE 1 - A tela de feedback deve exibir informações sobre o desempenho da pessoa, como o placar final e o número de perguntas que acertou
- O placar final deve ser mostrado em um elemento com o atributo
data-testid
com o valorfeedback-total-score
- O número de perguntas que a pessoa acertou deve ser exibido em um elemento com o atributo
data-testid
com o valorfeedback-total-question
O que será avaliado
- Não acertou nenhuma pergunta
- Acertou 2 perguntas
- Acertou 4 perguntas
PRIORIDADE 3 - A pessoa terá a opção "Jogar novamente", que ao ser clicada, levará para a tela de inicial
- Ao clicar no botão "Jogar novamente", a pessoa deve ser redirecionada para a tela de início (login)
- O botão para jogar novamente deve possuir o atributo
data-testid
com o valorbtn-play-again
O que será avaliado
- A pessoa deve ser redirecionada para tela inicial
PRIORIDADE 3 - Deve existir um botão que redirecione a pessoa para a tela de ranking
Observações técnicas
- Ao clicar no botão "Ver Ranking", a pessoa deve ser redirecionada para a tela de ranking
- O botão para ir para a tela de ranking deve possuir o atributo
data-testid
com o valorbtn-ranking
- A tela de ranking deve possuir um título com o atributo
data-testid
contendo o valorranking-title
O que será avaliado
- A pessoa deve ser redirecionada para tela de ranking
PRIORIDADE 1 - A tela de ranking deve possuir uma lista com a imagem, nome e pontuação das pessoas que jogaram e deve ficar armazenado no localStorage
Observações técnicas
- Deve-se mostrar uma lista com a imagem de perfil vinda do Gravatar, nome e pontuação das pessoas que jogaram em ordem decrescente (da maior pontuação para a menor)
- Os elementos com os nomes das pessoas que jogaram devem possuir o atributo
data-testid
com o valorplayer-name-${index}
, onde${index}
é iniciado em zero - Os elementos com as pontuações das pessoas que jogaram devem possuir o atributo
data-testid
com o valorplayer-score-${index}
, onde${index}
é iniciado em zero - O ranking deve ser armazenado no navegador através do
localStorage
. - Leia a seção "Implementações técnicas" para mais detalhes
O que será avaliado
- Deve existir uma pessoa no ranking
- Devem existir duas pessoas no ranking
- O ranking deve ser ordenado pela pontuação
PRIORIDADE 3 - O botão deve redirecionar a pessoa para a tela de inicial (login)
Observações técnicas
- Esse botão deve possuir o atributo
data-testid
com o valorbtn-go-home
- Esse botão deve enviar a pessoa para o início (tela de preenchimento dos dados)
O que será avaliado
- Volta para a tela inicial
19. Ao mudar o valor do dropdown categoria, apenas perguntas da categoria selecionada devem aparecer para a pessoa que está jogando. Essa configuração será identificada pela chave category no retorno da API;
20. Ao mudar o valor do dropdown dificuldade, apenas perguntas da dificuldade selecionada devem aparecer para a pessoa que está jogando. Essa configuração será identificada pela chave difficulty no retorno da API;
21. Ao mudar o valor do dropdown tipo, apenas perguntas do tipo selecionado devem aparecer para a pessoa que está jogando. Essa configuração será identificada pela chave type no retorno da API.
Obs: A maneira como a API deve ser estruturada segue o seguinte modelo: https://opentdb.com/api_config.php
-
Faça
commits
das alterações que você fizer no código regularmente -
Lembre-se de sempre após um (ou alguns)
commits
atualizar o repositório remoto -
Os comandos que você utilizará com mais frequência são:
git status
(para verificar o que está em vermelho - fora do stage - e o que está em verde - no stage)git add
(para adicionar arquivos ao stage do Git)git commit
(para criar um commit com os arquivos que estão no stage do Git)git push -u nome-da-branch
(para enviar o commit para o repositório remoto na primeira vez que fizer opush
de uma nova branch)git push
(para enviar o commit para o repositório remoto após o passo anterior)
Para "entregar" seu projeto, siga os passos a seguir:
- Vá até a página DO SEU Pull Request, adicione a label de "code-review" e marque seus colegas
- No menu à direita, clique no link "Labels" e escolha a label code-review
- No menu à direita, clique no link "Assignees" e escolha o seu usuário
- No menu à direita, clique no link "Reviewers" e digite
students
, selecione o timetryber/students-sd-06
Se ainda houver alguma dúvida sobre como entregar seu projeto, aqui tem um video explicativo.
À medida que você e as outras pessoas que estudam na Trybe forem entregando os projetos, vocês receberão um alerta via Slack para também fazer a revisão dos Pull Requests dos seus colegas. Fiquem atentos às mensagens do "Pull Reminders" no Slack!
Use o material que você já viu sobre Code Review para te ajudar a revisar os projetos que chegaram para você.
Ao finalizar e submeter o projeto, não se esqueça de avaliar sua experiência preenchendo o formulário. Leva menos de 3 minutos!
Link: FORMULÁRIO DE AVALIAÇÃO DE PROJETO
O avaliador automático não necessariamente avalia seu projeto na ordem em que os requisitos aparecem no readme. Isso acontece para deixar o processo de avaliação mais rápido. Então, não se assuste se isso acontecer, ok?