Solution made using react together with tools like useState and useEff

Community feedback

• 

  Bernardo Poggioni•6,790

  @R3ygoski

  Posted about 1 month ago

  Olá Evellyn, parabéns pela conclusão do projeto. Eu o baixei e vi que ele está muitíssimo bem-feito.

  Vou iniciar respondendo sobre a parte de dúvidas, começando pela parte de commits profissionais. Bom a melhor forma de fazer um commit é deixar claro o que aquele commit altera e sempre na forma infinitiva, por exemplo, você criou um novo componente, então faria sentido um commit assim: create new component. Além do mais existe uma convenção de commits que seria essa: Conventional Commits. Essa forma trabalha com uma padronização de commit, alguns exemplos:

  • feat(frontend): create a card component
  • refactor(backend): optimize X function
  • chore: update tailwind config

  Sobre o CSS, falarei sobre ele no final.

  Sobre estar uma bagunça, eu não acho que tenha ficado uma bagunça estrutural, mas ele possui alguns trechos que podem trazer problemas de legibilidade e manutenção. Por exemplo, tem funções que você utiliza snake_case ou PascalCase ao invés de camelCase, o que gera uma inconsistência e foge da convenção do JS. Outro problema seria uma pequena inconsistência no idioma como quantidade e itens-to-car(em inglês é items) enquanto outras classes estão em inglês. E um último problema seria erros gramaticais, como car ao invés de cart, hiden que aliás, note que já tem uma classe hidden, tanto que você teve que criar duas classes, sendo que poderia utilizar uma.

  Agora sobre algumas outras partes que você comentou. Você citou que poderia usar o hook useLocation, mas sinceramente não vejo onde ele poderia ser aplicado na aplicação, tanto que ele é do React-Router, e não há roteamento nesse desafio. Já sobre a Context API, sim, era possível utilizar ele.

  Você também citou que teve dúvidas se seria necessário rotas e o que seria componente. Bom, sobre componentes é realmente bem difícil identificar o que pode ser um componente independente ou não, mas geralmente cada elemento visual em uma tela pode ser um componente. Sobre as rotas, não, esse projeto não abre margem para trabalhar com rotas.

  Uma observação, sua estrutura do projeto está algo assim:

  ├──products
  ├──package.json
  ├──package-lock.json
  └──README
  

  Acredito que isso tenha sido uma distração, pois a pasta products é sua pasta principal, é nela onde está a aplicação, tanto que esse package.json externo está fazendo a instalação do fontawesome, mas tudo isso poderia ser feito dentro da pasta products. Tanto que isso evitaria a necessidade de utilizar o npm install duas vezes, e ajudaria na organização de pastas.

  Outra dica, dentro da sua products você também poderia instalar o json-server com o npm i json-server, assim colocando-o como dependência do projeto, aí quando fosse feito o npm i para criar o node_modules isso já instalaria o json-server permitindo que quem clonar o projeto tenha acesso a ela sem ter que instalar globalmente. Tanto que acredito que você não a instalou no projeto porque você já a tem instalada globalmente.

  Já sobre isso de utilizar json-server para fazer um mock de Backend, eu achei criativo, superinteressante e uma ideia inovadora dentro do contexto desse desafio. Então, parabéns!

  Mas note que isso trouxe um problema, sua aplicação tem um loading infinito pois faz uma busca no localhost:3000/producs acontece que, quando você faz o deploy, essa rota não existe. Para evitar isso você pode não utilizar o json-server ou utilizar alguma tech para criar o Backend, como o NestJS por exemplo, e hospedar ele em alguma plataforma como Railway, Render, entre outras. Mas note que o NestJS é bem robusto o que pode ser um "overkill" para esse desafio.

  Outra forma de você poder utilizar esse Backend e sem precisar usar outras techs seria utilizar o NextJS, pois ele já tem uma API embutida, daí você cria sua API ali dentro do Next e publica na Vercel, que aí ela já sobe sua API automaticamente. Mas note que pra isso terá que ter um conhecimento básico de HTTP e NodeJS.

  Edit: NextJS utiliza React, então se você já está confortável e sabe usar React, não vai ser tão difícil usar NextJS. E uma curiosidade, ele já tem um roteador embutido, então não é necessário um react-router.

  Agora sobre sua dúvida quanto ao CSS, ele está em grande parte bom, só que há problema de responsividade em telas menores que 425px. Isso ocorre devido a classe .itens-to-car ter um width: 400px, isso força o elemento a ter 400px de largura, que por sua vez faz com que o div.car não consiga diminuir, pois é valor auto. Então esse width pode ser removido em telas abaixo de 425px, e adicionar em telas acima de 425px.

  E é isso! Novamente parabéns, achei superinteressante isso de utilizar um mock de backend. Caso tenha ficado qualquer dúvida, por favor comente abaixo que tentarei ajudar da melhor forma possível.

  11

  Marked as helpful
• 

  jabo Landry•250

  @jabo-arnold-landry

  Posted about 1 month ago

  I could recommend to not use fixed width like instead of explicit setting width to some value like this: width:2rem; you could write it like this may be max-width:2rem; This means that no matter how the screen size is the width of an element will not grow beyond that value,so you can use min when you want it to not shrink beyond a certain point, you can also use @container queries since you are using React container query works the same as @media query the only difference is that with container queries the width will consider the width of it's container width while media queries consider the screen size.

  Last but not least try not use px when setting margins and width and heights try using em and rem.

  And when you commit try to commit key changes or functionalities you added or removed which are vital or a big issue it is not mandatory to commit every change you made.

  Hope it was helpful

  01

  Marked as helpful