Skip to content

lmuffato/Project-trivia-react-redux-Trybe

Repository files navigation

Termos de acordo

Ao iniciar este projeto, você concorda com as diretrizes do Código de Ética e Conduta e do Manual da Pessoa Estudante da Trybe.

Boas vindas ao repositório do projeto de Trivia!

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.


Sumário


Habilidades

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.


Entregáveis

Para entregar o seu projeto você deverá criar um Pull Request neste repositório.

Lembre-se que você pode consultar nosso conteúdo sobre Git & GitHub sempre que precisar!


O que deverá ser desenvolvido

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. Confira o Slack para saber como acessar o quadro! 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. É 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á. 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.

Desenvolvimento

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.


Data de entrega

  • Projeto em grupo.

  • Serão cinco dias de projeto.

  • Data de entrega para avaliação final do projeto: 25/06/2021 - 14:00h.


Instruções para entregar seu projeto:

Antes de começar a desenvolver:

  1. Clone o repositório
  • git clone git@github.com:tryber/sd-010-a-project-trivia-react-redux.git.
  • Entre na pasta do repositório que você acabou de clonar:
    • cd sd-010-a-project-trivia-react-redux
  • Vá para a branch do seu grupo, com git checkout main-group-XX && git pull, onde XX é o número do seu grupo. Exemplos: main-group-1, main-group-22.
  1. 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)
  1. 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
  • Se não estiver, mude para a branch main-group-XX
    • Exemplo: git checkout main-group-XX && git pull
  • 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
  1. 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)
  • 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)
  • Faça seus commit
    • Exemplo:
      • git commit -m 'cria componente de input
      • git status (deve aparecer uma mensagem tipo nothing to commit )
  1. 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
  1. 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
  1. 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"

Durante o desenvolvimento

⚠️ PULL REQUESTS COM ISSUES NO LINTER NÃO SERÃO AVALIADAS, ATENTE-SE PARA RESOLVÊ-LAS ANTES DE FINALIZAR O DESENVOLVIMENTO! ⚠️

  • 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:

    1. git status (para verificar o que está em vermelho - fora do stage - e o que está em verde - no stage)
    2. git add (para adicionar arquivos ao stage do Git)
    3. git commit (para criar um commit com os arquivos que estão no stage do Git)
    4. git push -u nome-da-branch (para enviar o commit para o repositório remoto na primeira vez que fizer o push de uma nova branch)
    5. git push (para enviar o commit para o repositório remoto após o passo anterior)

Depois de terminar o desenvolvimento (opcional)

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 time tryber/students-sd-010-a

Se ainda houver alguma dúvida sobre como entregar seu projeto, aqui tem um video explicativo.

⚠️ Lembre-se que garantir que todas as issues comentadas pelo Linter estão resolvidas! ⚠️

Revisando um pull request

À 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ê.


Como desenvolver

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 o git 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 branch main-group-XX do seu grupo, como no exemplo abaixo:

Exemplo de como apontar uma Pull Request para a branch main do grupo

  • 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

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.


Linter

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 e StyleLint. Para rodar o linter localmente no seu projeto, execute os comandos abaixo:

npm run lint
npm run lint:styles

PULL REQUESTS COM ISSUES DE LINTER NÃO SERÃO AVALIADAS. ATENTE-SE PARA RESOLVÊ-LAS ANTES DE FINALIZAR O DESENVOLVIMENTO!


Execução de testes de requisito

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.

⚠️ É MUITO importante utilizar, neste projeto, React com Redux para controlar a disseminação de informação entre os seus componentes. Por isso, no LocalStrage só é permitido haver três chaves (state, token e ranking) e isso será verificado nos testes! ⚠️


API de Trivia

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":[]
}

Gravatar

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).toString();

Atenção: Precisamos utilizar o toString() ao final da conversão.

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" />


Grupos de prioridade

Os requisitos são organizados por grupos de prioridade por tela. O objetivo é que o grupo possa se organizar melhor para que uma pessoa não fique totalmente dependente de outra para começar uma tarefa de outra tela. 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.
  • O primeiro requisito da tela de Jogo "Crie um header que deve conter as informações da pessoa jogadora" tem prioridade 1, ou seja, ele pode ser criado em paralelo mas depende das informações vindas da tela de Jogo para que o requisito seja aprovado.
  • Prioridades 2 são aquelas que dependem de outros requisitos, por exemplo, "A pergunta deve ter apenas uma alternativa correta", ou seja, depende que o requisito 1 esteja pronto para ser realizada.
  • Prioridades 3 são os ajustes finais, de prioridade baixa, que podem ou não depender de outros requisitos mas que não possuem dependentes.

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.


Observações técnicas

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.

Requisitos do projeto

⚠️ Lembre-se que o seu projeto só será avaliado se estiver passando pelos checks do Linter ⚠️

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.

Tela de início/login

1. Crie a tela de login, onde a pessoa que joga deve preencher as informações para iniciar um jogo

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 valor input-player-name
  • O campo de texto para o email deve possuir o atributo data-testid com o valor input-gravatar-email
  • O botão "Jogar" que leva a pessoa ao jogo deve possuir o atributo data-testid com o valor btn-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

2. Crie o botão de iniciar o jogo

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 chave token

O que será avaliado

  • Inicia jogo salvando um token de jogador

3. Crie um botão que leva a pessoa para tela de configuração

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 valor btn-settings
  • A tela de configurações deve possuir um título com o atributo data-testid contendo o valor settings-title

O que será avaliado

  • O botão deve existir na página
  • A tela de configurações deve possuir um título

Tela de jogo

4. Crie um header que deve conter as informações da pessoa jogadora

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 valor header-profile-picture
  • O nome da pessoa em um elemento que deve possuir o atributo data-testid com o valor header-player-name
  • O placar zerado em um elemento que deve possuir o atributo data-testid com o valor header-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

5. Crie a página de jogo que deve conter as informações relacionadas à pergunta

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 valor question-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 valor question-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 valor correct-answer
    • Os elementos com as alternativas incorretas devem possuir o atributo data-testid com o valor wrong-answer-${index}, com ${index} iniciando com o valor 0
    • As alternativas devem ser exibidas em ordem aleatória
    • Dica: utilize botões (<button/>) para as alternativas

O que será avaliado

  • A categoria da pergunta está presente
  • O texto da pergunta está presente
  • As alternativas devem estar presentes

6. Desenvolva o jogo onde só deve ser possível escolher uma resposta correta por pergunta

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 valor 3px solid rgb(6, 240, 15) para a alternativa correta.
  • Utilize a propriedade css border com o valor 3px 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

8. Desenvolva um timer onde a pessoa que joga tem 30 segundos para responder

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

9. Crie o placar com as seguintes características:

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 Observaçõ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

10. Crie um botão de "próxima" que apareça após a resposta ser dada

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 valor btn-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

11. Desenvolva o jogo de forma que a pessoa que joga deve responder 5 perguntas no total

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 elemento da mensagem de feedback deve possuir o atributo data-testid com o valor feedback-text

O que será avaliado

  • Acerta todas as perguntas
  • Erra todas as perguntas
  • Redireciona para a tela de feedback após a quinta pergunta

Tela de feedback

12. Desenvolva o header de feedback que deve conter as informações da pessoa jogadora

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 valor header-profile-picture
  • O nome da pessoa em um elemento que deve possuir o atributo data-testid com o valor header-player-name
  • O placar com o valor atual em um elemento que deve possuir o atributo data-testid com o valor header-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

13. Crie a mensagem de feedback para ser exibida a pessoa usuária

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 valor feedback-text

O que será avaliado

  • Acertou menos de 3 perguntas
  • Acertou 3 perguntas
  • Acertou mais de 3 perguntas

14. Exiba as informações relacionadas aos resultados obtidos para a pessoa usuária

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 valor feedback-total-score
  • O número de perguntas que a pessoa acertou deve ser exibido em um elemento com o atributo data-testid com o valor feedback-total-question

O que será avaliado

  • Não acertou nenhuma pergunta
  • Acertou 2 perguntas
  • Acertou 4 perguntas

15. Crie a opção para a pessoa jogadora poder jogar novamente

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 valor btn-play-again

O que será avaliado

  • A pessoa deve ser redirecionada para tela inicial

16. Crie a opção para a pessoa jogadora poder visualizar a tela de ranking

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 valor btn-ranking
  • A tela de ranking deve possuir um título com o atributo data-testid contendo o valor ranking-title

O que será avaliado

  • A pessoa deve ser redirecionada para tela de ranking

Tela de ranking

17. Crie a tela de ranking

PRIORIDADE 2 - 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 valor player-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 valor player-score-${index}, onde ${index} é iniciado em zero
  • O ranking deve ser armazenado no navegador através do localStorage.
  • Leia a seção Observaçõ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

18. Crie um botão para ir ao início

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 valor btn-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

Extra não avaliativo: Tela de configurações

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


Avisos finais

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?


Você sabia que o LinkedIn é a principal rede social profissional e compartilhar o seu aprendizado lá é muito importante para quem deseja construir uma carreira de sucesso? Compartilhe esse projeto no seu LinkedIn, marque o perfil da Trybe (@trybe) e mostre para a sua rede toda a sua evolução.