Skip to content

esterrochasoares/DinDin

BranchesTags

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
BackEND
BackEND
 
 
FrontEND
FrontEND
 
 
README.md
README.md
 
 

Repository files navigation

Desafio Back-end | Módulo 3

Seu papel é construir uma RESTful API que permita:

  • Cadastrar Usuário
  • Fazer Login
  • Detalhar Perfil do Usuário Logado
  • Editar Perfil do Usuário Logado
  • Listar categorias
  • Listar transações
  • Detalhar transação
  • Cadastrar transação
  • Editar transação
  • Remover transação
  • Obter extrato de transações
  • [Extra] Filtrar transações por categoria

Importante: Lembre-se sempre que cada usuário só pode ver e manipular seus próprios dados e suas próprias transações. Não atender a este pré-requisito é uma falha de segurança gravíssima!

Importante 2: O diretório ".github" e seu conteúdo não podem ser alterados e muito menos excluídos

Importante 3: Sempre que a validação de uma requisição falhar, responda com código de erro e mensagem adequada à situação, ok?

Importante 4: O link de acesso a esta API se encontra no final deste README. Este link é somente para testes (ou seja, será possível realizar requisições a esta API através do link fornecido visando AUXILIAR principalmente o desenvolvimento do desafio de Front-end, o que permitirá o desenvolvimento em paralelo de ambos os desafios)!

Exemplo:

// Quando é informado um id de transação que não existe:
// HTTP Status 404
{
    "mensagem": "Transação não encontrada!"
}

Banco de dados

Você precisa criar um Banco de Dados PostgreSQL chamado dindin contendo as seguintes tabelas e colunas:
ATENÇÃO! Os nomes das tabelas e das colunas a serem criados devem seguir exatamente os nomes listados abaixo.

  • usuarios
    • id
    • nome
    • email (campo único)
    • senha
  • categorias
    • id
    • descricao
  • transacoes
    • id
    • descricao
    • valor
    • data
    • categoria_id
    • usuario_id
    • tipo

IMPORTANTE: Deverá ser criado no projeto o(s) arquivo(s) SQL que deverá ser o script que cria as tabelas corretamente.

As categorias a seguir precisam ser previamente cadastradas para que sejam listadas no endpoint de listagem das categorias.

Categorias

  • Alimentação
  • Assinaturas e Serviços
  • Casa
  • Mercado
  • Cuidados Pessoais
  • Educação
  • Família
  • Lazer
  • Pets
  • Presentes
  • Roupas
  • Saúde
  • Transporte
  • Salário
  • Vendas
  • Outras receitas
  • Outras despesas

IMPORTANTE: Deverá ser criado no projeto o arquivo SQL que deverá ser o script de inserção das categorias acima na tabela.

Requisitos obrigatórios

  • A API a ser criada deverá acessar o banco de dados a ser criado "dindin" para persistir e manipular os dados de usuários, categorias e transações utilizados pela aplicação.
  • O campo id das tabelas no banco de dados deve ser auto incremento, chave primária e não deve permitir edição uma vez criado.
  • Seu código deverá estar organizado, delimitando as responsabilidades de cada arquivo adequadamente. Ou seja, é esperado que ele tenha, no mínimo:
    • Um arquivo index.js
    • Um arquivo conexao.js
    • Um arquivo de rotas
    • Um pasta com controladores
  • Qualquer valor monetário deverá ser representado em centavos (Ex.: R$ 10,00 reais = 1000)
  • Evite códigos duplicados. Antes de copiar e colar, pense se não faz sentido esse pedaço de código estar centralizado numa função.

Status Codes

Abaixo, listamos os possíveis status codes esperados como resposta da API.

// 200 (OK) = requisição bem sucedida
// 201 (Created) = requisição bem sucedida e algo foi criado
// 204 (No Content) = requisição bem sucedida, sem conteúdo no corpo da resposta
// 400 (Bad Request) = o servidor não entendeu a requisição pois está com uma sintaxe/formato inválido
// 401 (Unauthorized) = o usuário não está autenticado (logado)
// 403 (Forbidden) = o usuário não tem permissão de acessar o recurso solicitado
// 404 (Not Found) = o servidor não pode encontrar o recurso solicitado

Endpoints

Pessoa A

Cadastrar usuário

POST /usuario

Essa é a rota que será utilizada para cadastrar um novo usuario no sistema.

  • Requisição
    Sem parâmetros de rota ou de query.
    O corpo (body) deverá possuir um objeto com as seguintes propriedades (respeitando estes nomes):

    • nome
    • email
    • senha

  • Resposta
    Em caso de sucesso, deveremos enviar no corpo (body) da resposta o conteúdo do usuário cadastrado, incluindo seu respectivo id e excluindo a senha criptografada. Em caso de falha na validação, a resposta deverá possuir status code apropriado, e em seu corpo (body) deverá possuir um objeto com uma propriedade mensagem que deverá possuir como valor um texto explicando o motivo da falha.

  • REQUISITOS OBRIGATÓRIOS

    • Validar os campos obrigatórios:
      • nome
      • email
      • senha
    • Validar se o e-mail informado já existe
    • Criptografar a senha antes de persistir no banco de dados
    • Cadastrar o usuário no banco de dados

Exemplo de requisição

// POST /usuario
{
    "nome": "José",
    "email": "[email protected]",
    "senha": "123456"
}

Exemplos de resposta

// HTTP Status 200 / 201 / 204
{
    "id": 1,
    "nome": "José",
    "email": "[email protected]"
}
// HTTP Status 400 / 401 / 403 / 404
{
    "mensagem": "Já existe usuário cadastrado com o e-mail informado."
}

Pessoa A

Login do usuário

POST /login

Essa é a rota que permite o usuario cadastrado realizar o login no sistema.

  • Requisição
    Sem parâmetros de rota ou de query.
    O corpo (body) deverá possuir um objeto com as seguintes propriedades (respeitando estes nomes):

    • email
    • senha

  • Resposta
    Em caso de sucesso, o corpo (body) da resposta deverá possuir um objeto com a propriedade token que deverá possuir como valor o token de autenticação gerado e uma propriedade usuario que deverá possuir as informações do usuário autenticado, exceto a senha do usuário.
    Em caso de falha na validação, a resposta deverá possuir status code apropriado, e em seu corpo (body) deverá possuir um objeto com uma propriedade mensagem que deverá possuir como valor um texto explicando o motivo da falha.

  • REQUISITOS OBRIGATÓRIOS

    • Validar os campos obrigatórios:
      • email
      • senha
    • Verificar se o e-mail existe
    • Validar e-mail e senha
    • Criar token de autenticação com id do usuário

Exemplo de requisição

// POST /login
{
    "email": "[email protected]",
    "senha": "123456"
}

Exemplos de resposta

// HTTP Status 200 / 201 / 204
{
    "usuario": {
        "id": 1,
        "nome": "José",
        "email": "[email protected]"
    },
    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MiwiaWF0IjoxNjIzMjQ5NjIxLCJleHAiOjE2MjMyNzg0MjF9.KLR9t7m_JQJfpuRv9_8H2-XJ92TSjKhGPxJXVfX6wBI"
}
// HTTP Status 400 / 401 / 403 / 404
{
    "mensagem": "Usuário e/ou senha inválido(s)."
}

ATENÇÃO: Todas as funcionalidades (endpoints) a seguir, a partir desse ponto, deverão exigir o token de autenticação do usuário logado, recebendo no header com o formato Bearer Token. Portanto, em cada funcionalidade será necessário validar o token informado

Validações do token

  • REQUISITOS OBRIGATÓRIOS
    • Validar se o token foi enviado no header da requisição (Bearer Token)
    • Verificar se o token é válido
    • Consultar usuário no banco de dados pelo id contido no token informado

Pessoa B

Detalhar usuário

GET /usuario

Essa é a rota que será chamada quando o usuario quiser obter os dados do seu próprio perfil.
Atenção!: O usuário deverá ser identificado através do ID presente no token de autenticação.

  • Requisição
    Sem parâmetros de rota ou de query.
    Não deverá possuir conteúdo no corpo da requisição.

  • Resposta
    Em caso de sucesso, o corpo (body) da resposta deverá possuir um objeto que representa o usuário encontrado, com todas as suas propriedades (exceto a senha), conforme exemplo abaixo, acompanhado de status code apropriado.
    Em caso de falha na validação, a resposta deverá possuir status code apropriado, e em seu corpo (body) deverá possuir um objeto com uma propriedade mensagem que deverá possuir como valor um texto explicando o motivo da falha.
    Dica: neste endpoint podemos fazer uso do status code 401 (Unauthorized).

Exemplo de requisição

// GET /usuario
// Sem conteúdo no corpo (body) da requisição

Exemplos de resposta

// HTTP Status 200 / 201 / 204
{
    "id": 1,
    "nome": "José",
    "email": "[email protected]"
}
// HTTP Status 400 / 401 / 403 / 404
{
    "mensagem": "Para acessar este recurso um token de autenticação válido deve ser enviado."
}

Pessoa B

Atualizar usuário

PUT /usuario

Essa é a rota que será chamada quando o usuário quiser realizar alterações no seu próprio usuário.
Atenção!: O usuário deverá ser identificado através do ID presente no token de autenticação.

  • Requisição
    Sem parâmetros de rota ou de query.
    O corpo (body) deverá possuir um objeto com as seguintes propriedades (respeitando estes nomes):

    • nome
    • email
    • senha

  • Resposta
    Em caso de sucesso, não deveremos enviar conteúdo no corpo (body) da resposta.
    Em caso de falha na validação, a resposta deverá possuir status code apropriado, e em seu corpo (body) deverá possuir um objeto com uma propriedade mensagem que deverá possuir como valor um texto explicando o motivo da falha.

  • REQUISITOS OBRIGATÓRIOS

    • Validar os campos obrigatórios:
      • nome
      • email
      • senha
    • Validar se o novo e-mail já existe no banco de dados para outro usuário
      • Caso já exista o novo e-mail fornecido para outro usuário no banco de dados, a alteração não deve ser permitida (o campo de email deve ser sempre único no banco de dados)
    • Criptografar a senha antes de salvar no banco de dados
    • Atualizar as informações do usuário no banco de dados

Exemplo de requisição

// PUT /usuario
{
    "nome": "José de Abreu",
    "email": "[email protected]",
    "senha": "j4321"
}

Exemplos de resposta

// HTTP Status 200 / 201 / 204
// Sem conteúdo no corpo (body) da resposta
// HTTP Status 400 / 401 / 403 / 404
{
    "mensagem": "O e-mail informado já está sendo utilizado por outro usuário."
}

Pessoa B

Listar categorias

GET /categoria

Essa é a rota que será chamada quando o usuario logado quiser listar todas as categorias cadastradas.

  • Requisição
    Sem parâmetros de rota ou de query.
    Não deverá possuir conteúdo no corpo (body) da requisição.

  • Resposta
    Em caso de sucesso, o corpo (body) da resposta deverá possuir um array dos objetos (categorias) encontrados.
    Em caso de falha na validação, a resposta deverá possuir status code apropriado, e em seu corpo (body) deverá possuir um objeto com uma propriedade mensagem que deverá possuir como valor um texto explicando o motivo da falha.

  • REQUISITOS OBRIGATÓRIOS

    • O endpoint deverá responder com um array de todas as categorias cadastradas.

Exemplo de requisição

// GET /categoria
// Sem conteúdo no corpo (body) da requisição

Exemplos de resposta

// HTTP Status 200 / 201 / 204
[
    {
        id: 1,
        descricao: "Roupas",
    },
    {
        id: 2,
        descricao: "Mercado",
    },
]
// HTTP Status 200 / 201 / 204
[]

Pessoa B

Listar transações do usuário logado

GET /transacao

Essa é a rota que será chamada quando o usuario logado quiser listar todas as suas transações cadastradas.
Lembre-se: Deverão ser retornadas apenas transações associadas ao usuário logado, que deverá ser identificado através do ID presente no token de validação.

  • Requisição
    Sem parâmetros de rota ou de query.
    Não deverá possuir conteúdo no corpo (body) da requisição.

  • Resposta
    Em caso de sucesso, o corpo (body) da resposta deverá possuir um array dos objetos (transações) encontrados.
    Em caso de falha na validação, a resposta deverá possuir status code apropriado, e em seu corpo (body) deverá possuir um objeto com uma propriedade mensagem que deverá possuir como valor um texto explicando o motivo da falha.

  • REQUISITOS OBRIGATÓRIOS

    • O usuário deverá ser identificado através do ID presente no token de validação
    • O endpoint deverá responder com um array de todas as transações associadas ao usuário. Caso não exista nenhuma transação associada ao usuário deverá responder com array vazio.

Exemplo de requisição

// GET /transacao
// Sem conteúdo no corpo (body) da requisição

Exemplos de resposta

// HTTP Status 200 / 201 / 204
[
    {
        id: 1,
        tipo: "saida",
        descricao: "Sapato amarelo",
        valor: 15800,
        data: "2022-03-23T15:35:00.000Z",
        usuario_id: 5,
        categoria_id: 4,
        categoria_nome: "Roupas",
    },
    {
        id: 3,
        tipo: "entrada",
        descricao: "Salário",
        valor: 300000,
        data: "2022-03-24T15:30:00.000Z",
        usuario_id: 5,
        categoria_id: 6,
        categoria_nome: "Salários",
    },
]
// HTTP Status 200 / 201 / 204
[]

Pessoa A

Detalhar uma transação do usuário logado

GET /transacao/:id

Essa é a rota que será chamada quando o usuario logado quiser obter uma das suas transações cadastradas.
Lembre-se: Deverá ser retornado apenas transação associada ao usuário logado, que deverá ser identificado através do ID presente no token de validação.

  • Requisição
    Deverá ser enviado o ID da transação no parâmetro de rota do endpoint.
    O corpo (body) da requisição não deverá possuir nenhum conteúdo.

  • Resposta
    Em caso de sucesso, o corpo (body) da resposta deverá possuir um objeto que representa a transação encontrada, com todas as suas propriedades, conforme exemplo abaixo, acompanhado de status code apropriado.
    Em caso de falha na validação, a resposta deverá possuir status code apropriado, e em seu corpo (body) deverá possuir um objeto com uma propriedade mensagem que deverá possuir como valor um texto explicando o motivo da falha.

  • REQUISITOS OBRIGATÓRIOS

    • Validar se existe transação para o id enviado como parâmetro na rota e se esta transação pertence ao usuário logado.

Exemplo de requisição

// GET /transacao/2
// Sem conteúdo no corpo (body) da requisição

Exemplos de resposta

// HTTP Status 200 / 201 / 204
{
    "id": 2,
    "tipo": "entrada",
    "descricao": "Salário",
    "valor": 300000,
    "data": "2022-03-24T15:30:00.000Z",
    "usuario_id": 5,
    "categoria_id": 6,
    "categoria_nome": "Salários",
}
// HTTP Status 400 / 401 / 403 / 404
{
    "mensagem": "Transação não encontrada."
}

Pessoa A

Cadastrar transação para o usuário logado

POST /transacao

Essa é a rota que será utilizada para cadastrar uma transação associada ao usuário logado.
Lembre-se: Deverá ser possível cadastrar apenas transações associadas ao próprio usuário logado, que deverá ser identificado através do ID presente no token de validação.

  • Requisição
    Sem parâmetros de rota ou de query.
    O corpo (body) da requisição deverá possuir um objeto com as seguintes propriedades (respeitando estes nomes):

    • descricao
    • valor
    • data
    • categoria_id
    • tipo (campo que será informado se a transação corresponde a uma saída ou entrada de valores)

  • Resposta Em caso de sucesso, deveremos enviar, no corpo (body) da resposta, as informações da transação cadastrada, incluindo seu respectivo id.
    Em caso de falha na validação, a resposta deverá possuir status code apropriado, e em seu corpo (body) deverá possuir um objeto com uma propriedade mensagem que deverá possuir como valor um texto explicando o motivo da falha.

  • REQUISITOS OBRIGATÓRIOS

    • Validar os campos obrigatórios:
      • descricao
      • valor
      • data
      • categoria_id
      • tipo
    • Validar se existe categoria para o id enviado no corpo (body) da requisição.
    • Validar se o tipo enviado no corpo (body) da requisição corresponde a palavra entrada ou saida, exatamente como descrito.
    • Cadastrar a transação associada ao usuário logado.

Exemplo de requisição

// POST /transacao
{
    "tipo": "entrada",
    "descricao": "Salário",
    "valor": 300000,
    "data": "2022-03-24T15:30:00.000Z",
    "categoria_id": 6
}

Exemplos de resposta

// HTTP Status 200 / 201 / 204
{
    "id": 3,
    "tipo": "entrada",
    "descricao": "Salário",
    "valor": 300000,
    "data": "2022-03-24T15:30:00.000Z",
    "usuario_id": 5,
    "categoria_id": 6,
    "categoria_nome": "Salários",
}
// HTTP Status 400 / 401 / 403 / 404
{
    "mensagem": "Todos os campos obrigatórios devem ser informados."
}

Pessoa B

Atualizar transação do usuário logado

PUT /transacao/:id

Essa é a rota que será chamada quando o usuario logado quiser atualizar uma das suas transações cadastradas.
Lembre-se: Deverá ser possível atualizar apenas transações associadas ao próprio usuário logado, que deverá ser identificado através do ID presente no token de validação.

  • Requisição
    Deverá ser enviado o ID da transação no parâmetro de rota do endpoint.
    O corpo (body) da requisição deverá possuir um objeto com as seguintes propriedades (respeitando estes nomes):

    • descricao
    • valor
    • data
    • categoria_id
    • tipo (campo que será informado se a transação corresponde a uma saída ou entrada de valores)

  • Resposta
    Em caso de sucesso, não deveremos enviar conteúdo no corpo (body) da resposta.
    Em caso de falha na validação, a resposta deverá possuir status code apropriado, e em seu corpo (body) deverá possuir um objeto com uma propriedade mensagem que deverá possuir como valor um texto explicando o motivo da falha.

  • REQUISITOS OBRIGATÓRIOS

    • Validar se existe transação para o id enviado como parâmetro na rota e se esta transação pertence ao usuário logado.
    • Validar os campos obrigatórios:
      • descricao
      • valor
      • data
      • categoria_id
      • tipo
    • Validar se existe categoria para o id enviado no corpo (body) da requisição.
    • Validar se o tipo enviado no corpo (body) da requisição corresponde a palavra entrada ou saida, exatamente como descrito.
    • Atualizar a transação no banco de dados

Exemplo de requisição

// PUT /transacao/2
{
 "descricao": "Sapato amarelo",
 "valor": 15800,
 "data": "2022-03-23 12:35:00",
 "categoria_id": 4,
 "tipo": "saida"
}

Exemplos de resposta

// HTTP Status 200 / 201 / 204
// Sem conteúdo no corpo (body) da resposta
// HTTP Status 400 / 401 / 403 / 404
{
    "mensagem": "Todos os campos obrigatórios devem ser informados."
}

Pessoa B

Excluir transação do usuário logado

DELETE /transacao/:id

Essa é a rota que será chamada quando o usuario logado quiser excluir uma das suas transações cadastradas.
Lembre-se: Deverá ser possível excluir apenas transações associadas ao próprio usuário logado, que deverá ser identificado através do ID presente no token de validação.

  • Requisição
    Deverá ser enviado o ID da transação no parâmetro de rota do endpoint.
    O corpo (body) da requisição não deverá possuir nenhum conteúdo.

  • Resposta
    Em caso de sucesso, não deveremos enviar conteúdo no corpo (body) da resposta.
    Em caso de falha na validação, a resposta deverá possuir status code apropriado, e em seu corpo (body) deverá possuir um objeto com uma propriedade mensagem que deverá possuir como valor um texto explicando o motivo da falha.

  • REQUISITOS OBRIGATÓRIOS:

    • Validar se existe transação para o id enviado como parâmetro na rota e se esta transação pertence ao usuário logado.
    • Excluir a transação no banco de dados.

Exemplo de requisição

// DELETE /transacao/2
// Sem conteúdo no corpo (body) da requisição

Exemplos de resposta

// HTTP Status 200 / 201 / 204
// Sem conteúdo no corpo (body) da resposta
// HTTP Status 400 / 401 / 403 / 404
{
    "mensagem": "Transação não encontrada."
}

Pessoa A

Obter extrato de transações

GET /transacao/extrato

Essa é a rota que será chamada quando o usuario logado quiser obter o extrato de todas as suas transações cadastradas. Lembre-se: Deverá ser possível consultar apenas transações associadas ao próprio usuário logado, que deverá ser identificado através do ID presente no token de validação.

  • Requisição
    Sem parâmetros de rota ou de query.
    O corpo (body) da requisição não deverá possuir nenhum conteúdo.

  • Resposta
    Em caso de sucesso, deveremos enviar no corpo (body) da resposta um objeto contendo a soma de todas as transações do tipo entrada e a soma de todas as transações do tipo saida.
    Em caso de falha na validação, a resposta deverá possuir status code apropriado, e em seu corpo (body) deverá possuir um objeto com uma propriedade mensagem que deverá possuir como valor um texto explicando o motivo da falha.

  • REQUISITOS OBRIGATÓRIOS:

    • Em caso de não existir transações do tipo entrada cadastradas para o usuário logado, o valor retornado no corpo (body) da resposta deverá ser 0.
    • Em caso de não existir transações do tipo saida cadastradas para o usuário logado, o valor retornado no corpo (body) da resposta deverá ser 0.

Importante: A criação desta rota, no arquivo rotas.js, deverá acontecer antes da criação da rota de detalhamento de uma transação (GET /transacao/:id), caso contrário, esta rota nunca será possível ser acessada.

Exemplo de requisição

// GET /transacao/extrato
// Sem conteúdo no corpo (body) da requisição

Exemplos de resposta

// HTTP Status 200 / 201 / 204
{
 "entrada": 300000,
 "saida": 15800
}

Pessoa A

EXTRA

ATENÇÃO!: Esta parte extra não é obrigatória e recomendamos que seja feita apenas quando terminar toda a parte obrigatória acima.

Filtrar transações por categoria

Na funcionalidade de listagem de transações do usuário logado (GET /transacao), deveremos incluir um parâmetro do tipo query filtro para que seja possível consultar apenas transações das categorias informadas.

Lembre-se: Deverão ser retornadas apenas transações associadas ao usuário logado, que deverá ser identificado através do ID presente no token de validação.

  • Requisição
    Parâmetro opcional do tipo query filtro. Não deverá possuir conteúdo no corpo (body) da requisição.

  • Resposta
    Em caso de sucesso, o corpo (body) da resposta deverá possuir um array dos objetos (transações) encontradas.
    Em caso de falha na validação, a resposta deverá possuir status code apropriado, e em seu corpo (body) deverá possuir um objeto com uma propriedade mensagem que deverá possuir como valor um texto explicando o motivo da falha.

  • REQUISITOS OBRIGATÓRIOS

    • O usuário deverá ser identificado através do ID presente no token de validação
    • O parâmetro opcional do tipo query filtro, quando enviado, deverá ser sempre um array contendo a descrição de uma ou mais categorias.
    • O endpoint deverá responder com um array de todas as transações associadas ao usuário que sejam da categorias passadas no parâmetro query. Caso não exista nenhuma transação associada ao usuário deverá responder com array vazio.

Exemplo de requisição

// GET /transacao?filtro[]=roupas&filtro[]=salários
// Sem conteúdo no corpo (body) da requisição

Exemplos de resposta

// HTTP Status 200 / 201 / 204
[
    {
        id: 1,
        tipo: "saida",
        descricao: "Sapato amarelo",
        valor: 15800,
        data: "2022-03-23T15:35:00.000Z",
        usuario_id: 5,
        categoria_id: 11,
        categoria_nome: "Roupas",
    },
    {
        id: 3,
        tipo: "entrada",
        descricao: "Salário",
        valor: 300000,
        data: "2022-03-24T15:30:00.000Z",
        usuario_id: 5,
        categoria_id: 14,
        categoria_nome: "Salário",
    },
]
// HTTP Status 200 / 201 / 204
[]

Link do deploy da API somente para testes: link

Este link é somente para testes (ou seja, será possível realizar requisições a esta API através deste link visando AUXILIAR principalmente o desenvolvimento do desafio de Front-end, o que permitirá o desenvolvimento em paralelo de ambos os desafios)!

LEMBRE-SE: Feito é melhor que perfeito!!!

tags: back-end módulo 3 nodeJS PostgreSQL API REST desafio

Desafio | Front-end - Módulo 3

Após alguns meses trabalhando em projetos mais simples, você foi designado pelo seu Tech Lead para desenvolver uma aplicação que será apresentada a um cliente muito importante.

Para o seu desenvolvimento foi liberado o layout que você pode encontrar no seguinte link.

Além disso, você pode acessar o mapa mental com o mapeamento das funcionalidades clicando no seguinte link.

O sistema trata-se de uma aplicação para controle de finanças pessoais. As funcionalidades são:

  • Cadastro do usuário
  • Login de usuário
  • Cadastro de uma nova transação
  • Edição de uma transação
  • Exclusão de uma transação
  • Listagem de transações
  • Permitir ordenar a tabela por data
  • Na parte de resumo, o valor de entradas, saídas e saldo é obtido por meio do endpoint de extrato da API
  • Permitir o usuário filtrar a tabela por categoria
  • Editar perfil de usuário
  • Deslogar usuário

Detalhamento de Requisitos:

Pessoa A

Cadastro de um novo usuário:

Para cadastrar um novo usuário você terá que preencher o formulário na página de sign-up.

*É importante garantir que todos os campos estão preenchidos, além de que as senha e confirmação de senha são iguais.

Ao clicar no botão Cadastrar você deverá enviar os dados do formulário para a API fazendo com que o sistema registre um novo usuário, caso dê certo o cadastro de um novo usuário, devemos redirecionar o usuário para a tela de sign-in (login), assim ele já poderá se logar no sistema.

Pessoa A

Login de usuário:

  1. Na página de login de usuário, temos um botão chamado Cadastre-se, esse botão deve levar o usuário para a tela de cadastrar um novo usuário (sign-up):
  2. O formulário de login deve validar se os campos estão realmente preenchidos, se estiverem preenchidos você enviará uma requisição para a API para fazer o login desse usuário, é importante lembrar que existem informações como token e userId que precisam ser armazenadas no localStorage para que o usuário possa depois usar dentro da área logada.
  3. Caso o login dê certo o usuário deverá ser redirecionado para a tela principal (main) onde ele verá a listagem de suas transações.
  4. Caso o usuário esteja logado, nós devemos bloquear o acesso dele a página de login, sendo assim, somente quando o usuário estiver deslogado que poderá acessar a página sign-in (login).

Pessoa B

Página principal (main):

Após o usuário fazer o login ele será redirecionado para a página principal, essa página só poderá ser acessada por usuários que estão logados na aplicação, caso contrário ao tentar acessar a página principal sem estar logado o usuário deverá ser redirecionado para a página de login (sign-in).

Nessa página ele verá todas as informações:

  1. Header da aplicação com botões, logos e ícones.
  2. Tabela com a listagem de transações.
  3. Área de resumo, que traz as informações de entradas, saídas e saldos.
  4. Botão para adicionar uma nova transação.
  5. Botão para abrir área de filtros.

Veja na imagem abaixo:

Pessoa B

Cadastro de uma nova transação:

Para cadastrar uma nova transação o usuário deverá clicar no botão Adicionar Registro, que ficará logo abaixo da área de resumo.

Ao clicar no referido botão, um modal com a opção de adicionar informações de uma transação deve ser exibido:

  1. Nesse modal todas as informações devem ser preenchidas, lembrando que você pode adicionar uma entrada ou saída de dinheiro, por padrão o valor deve ser o de saída, caso o usuário queira adicionar um valor de entrada ele precisará clicar no botão Entrada.
  2. O select de Categoria deverá ser preenchido com as informações de categorias que a API traz, ou seja, as categorias devem ser listadas dentro do select com base em um GET na rota de categoria da API.

*Todos os campos são obrigatórios!

Após o usuário clicar no botão confirmar, uma nova transação deve ser inserida e a tabela de listagem deve ser atualizada.

É importante lembrar que quando adicionarmos uma nova transação, devemos atualizar também a área de RESUMO.

Pessoa B

Editar uma transação:

Para editar uma transação o usuário deverá clicar no ícone do lápis, que se encontrará na tabela de listagem de transações:

Esse ícone =>

Ao clicar no ícone de editar uma transação, o modal (que foi utilizado para adicionar uma nova transação) deverá ser aberto e as informações da transação "clicada", deverão ser preenchidas automaticamente, assim como a imagem abaixo:

*Novamente, todos os campos são obrigatórios!

Após validar os campos e o usuário clicar em confirmar, a transação deverá ser atualizada na API.

Pessoa B

Excluir uma transação:

Para excluir uma transação o usuário deverá clicar no ícone da lixeira, que se encontrará na tabela de listagem de transações:

Esse ícone =>

Ao clicar nesse ícone, um "popup" irá aparecer para que o usuário confirme ou não a exclusão, fazendo com que não hajam exclusões por engano, veja abaixo como aparece o "popup":

Pessoa B

Listagem de transações:

As transações registradas por meio dos endpoints da api, deverão ser listadas numa tabela que ficará ao centro da página, nessa tabela teremos 6 colunas, sendo:

  1. Data da transação no formato dd/mm/yyyy
  2. Dia da semana, nessa coluna deveremos utilizar apenas os primeiros nomes dos dias da semana, ao invéz de Segunda-Feira, deveremos utilizar o formato Segunda.
  3. Descrição, nessa coluna listaremos as descrições informadas no cadastro de transação.
  4. Categoria, aqui vamos mostrar as categorias inseridas em cada uma das transações cadastradas.
  5. Valor, nessa coluna exibiremos os valores de cada uma das transações. Existe uma regra importante nas cores e nos sinais, para valores de entrada de dinheiro (credit) exibimos o número positivo e na cor roxa, já para Saídas de dinheiro (debit) exibimos o número na cor laranja.
  6. Na última coluna nós não teremos um cabeçalho, nessa coluna ficarão os botões de editar e excluir.

Cada linha da tabela representa uma transação. Portanto cada botão representa a ação para um registro.

Pessoa A

Cabeçalho da tabela:

No cabeçalho da tabela deverá haver a opção de clicar e ordenar de forma crescente e decrescente, para isso basta o usuário clicar no nome da coluna, a cada clique a ordenação deve ser alterada entre crescente e decrescente.

Somente a coluna Data poderá ser ordenada:

Veja abaixo o ícone que representa que a coluna está sendo ordenada:

  • Ordenando a coluna data de forma crescente (do menor para o maior)

Importante: Somente a coluna em ordenação deve conter o ícone.

Pessoa A

Resumo das transações:

O resumo das transações devem ser exibidos numa "box", onde teremos apenas 3 informações:

  • Entradas
  • Saídas
  • Saldo

É importante ressaltar que os valores de entrada, saída e saldos são calculados com base em um endpoint da API que traz o extrato das transações.

Veja na imagem abaixo, como deve ser o resumo;

Pessoa A

Filtros:

A área de filtros por padrão é oculta, por isso você deve implementar a lógica para que quando o usuário clique no botão Filtrar a área de filtro seja exibida e quando clicar novamente seja ocultada, veja abaixo o botão que exibe/oculta a área de filtros:

Os filtros servem para dar granularidade aos dados, ou seja, para haver a possibilidade de exibir as transações conforme selecionamos requisitos para tal. Por exemplo, se disseremos que deve-se exibir apenas as transações da categoria Depósito, devemos listar na tabela somente as transações que pertencem àquela categoria.

Os filtros são cumulativos, ou seja, você pode filtrar por uma categoria ou por diversas categorias.

O funcionamento dos filtros segue a seguinte ordem:

  1. Seleciona-se os filtros de categoria
  2. Após selecionar os filtros desejados, clica-se no botão aplicar filtros.

Para limpar os filtros atuais, o usuário deverá clicar no botão limpar filtros

Importante:

  1. Ao clicar em aplicar filtros sem nenhum filtro selecionado, o sistema deve exibir todas as transações disponíveis cadastradas.
  2. Ao clicar em limpar filtros, o sistema deve exibir todas as transações disponíveis cadastradas.

Veja na imagem abaixo os botões:

Pessoa B

Editar perfil de usuário:

No header da aplicação existe um ícone:

Ao clicar nesse ícone, deverá ser exibido um modal para edição do usuário logado.

  1. O modal deverá abrir com os dados do usuário já carregados nele (menos senha e confirmação de senha)
  2. Após o usuário preencher os campos ele deverá clicar em confirmar, nesse momento você deve validar se os campos estão preenchidos, caso estejam, você deve enviar as informações que a API solicita para fazer a atualização do usuário logado.
  3. Após o perfil ter sido atualizado o modal deverá ser fechado.
  4. Ao abrir novamente o modal, os dados do usuário devem estar atualizados.

Veja na imagem o modal já preenchido:

Pessoa A

Logout e nome de usuário

No header da página principal (main) você deverá:

  1. Preencher com o nome do usuário logado no momento.
  2. Além de adicionar uma função para deslogar o usuário ao clicar no botão que tem uma imagem que sugere ao usuário que ele vai deslogar da aplicação.

Veja na imagem abaixo os ícones:

LEMBRE-SE: é melhor feito do que perfeito, mas não faça mal feito!!!

tags: front-end módulo 3 React CSS desafio

About

No description, website, or topics provided.

Resources

Readme
Activity

Stars

1 star

Watchers

1 watching

Forks

0 forks
Report repository

Releases

No releases published

Packages

No packages published

Languages