Conversation
primeiros setups
primeiros setups
Ajuste da posição do footer na página
primeiros setups
Tela de busca
Página de Cadastro
criacao da pagina de login
criacao da rota de login
Cadastro/Endereço
Tela de perfil
…rfil-endereço Acessar dados telas edição perfil endereço
implementação da requisição de pegar histórico de pedidos na tela de …
Tela carrinho
tentativa adicionar de produto
…dereço Renderização da tela de perfil após edição dos dados do usuário ou do…
adicionar e remover do carrinho ok
soma dos preços ok
atualizações cart
implementação funcionalidades feed page
estilização da feed page
ajustes na estilização
pdarvas
left a comment
pdarvas
left a comment
There was a problem hiding this comment.
Olá, pessoal!
Primeiro, gostaria de pedir desculpas pela demora em dar esse feedback.
Segundo, quero deixar meus parabéns!!! Pela entrega desse projeto e, principalmente, pelo final do curso.
O projeto em si ficou muito bom!!! Esse é um projeto muito complexo e comprido, e vocês fizeram uma entrega ótima! Ainda que tenha faltado um ou outro detalhe (e ficou claro que foi um problema de tempo), tudo funciona de uma forma muito consistente e coesa.
O código em geral tá muito organizado e lógica muito bem feita! Deixei alguns comentários em pontos específicos, mas que por vezes se repetem em outros locais. Esses comentários devem ser vistos como um aprendizado para a carreira de vocês, e não como algo a ser consertado nesse projeto aqui.
Quaisquer dúvidas fiquem a vontade pra me contatar lá no Slack!
Obrigado por toda a atenção e carinho durante esse período que passamos juntos. Espero que tenham aproveitado e que levem boas lembranças!
Mais uma vez, parabéns por terem chegado até aqui!!
|
|
||
| export const Container = styled.div` | ||
| height: 100vh; | ||
| width: 100vw; |
There was a problem hiding this comment.
Normalmente, não é necessário definir a largura da página dessa maneira.
Elementos block (tipo a div e a maioria dos outros elementos) automaticamente ocupam todo o espaço horizontal disponível.
Fixar a largura como 100vw pode trazer dores de cabeça com responsividade e comportamentos estranhos.
Não quer dizer que é errado, só não costuma ser necessário.
Se nesse caso era necessário, podem desconsiderar o comentário.
| @@ -0,0 +1,41 @@ | |||
| export const register = (history) => { | |||
There was a problem hiding this comment.
Nomes de funções devem indicar o que elas fazem, e nenhuma função desse arquivo faz isso.
Dá pra entender pelo contexto, especialmente na hora da declaração. Mas no momento do uso, fica bem confuso.
goToRegisterPage, goToAddressPage, e assim por diante seria melhor.
| const getShipping = () => { | ||
| const headers = { | ||
| headers: { | ||
| auth: localStorage.getItem('Token') | ||
| } | ||
| } | ||
|
|
||
| axios.get(`https://us-central1-missao-newton.cloudfunctions.net/futureEatsA/restaurants/${states.cart.restaurantId}`, headers).then((response) => { | ||
|
|
||
| setShipping(response.data.restaurant.shipping) | ||
| }).catch((error) => { | ||
| console.log(error) | ||
| }) | ||
| } |
There was a problem hiding this comment.
Essa função, bem como o estado shipping parecem não estar sendo usados. Se me lembro bem, tinha sido uma tentativa de pegar o preço do frete, que acabou sendo implementada de outra maneira, sem a necessidade da requisição. Dessa forma, o ideal é sempre apagar códigos não mais usados.
| name="state" | ||
| placeholder="Estado" | ||
| onChange={onChangeEditAddress} | ||
| style={{ margin: '0.5rem 0' }} |
There was a problem hiding this comment.
Evitar sempre que possível styles inline.
Poderia estilizar dessa forma:
const StyledTextField = styled(TextField)`
margin: 0.5rem 0;
`| const onChangeEditUser = (event)=>{ | ||
| const { value, name } = event.target; | ||
| setters.setUser({ ...states.user, [name]: value }); | ||
| } |
There was a problem hiding this comment.
Os inputs de edição do usuário estão alterando o mesmo estado que guarda os dados do usuário vindos da requisição.
Por mais que isso simplifique um pouco o código num momento inicial (pois fica mais simples preencher os inputs com os dados corretos), essa pode ser uma fonte de bugs esquisitos. Por exemplo, se o usuário entra na tela de edição de perfil, digita algo e volta pra tela anterior (sem salvar), as informações vão aparecer como se estivessem atualizadas e salvas.
O ideal, portanto, é ter um estado local para guardar os valores dos formulários. Ai, é possível usar um useEffect para atualizar os estados locais com os dados vindos do estado global, preenchendo os campos com os dados do usuário. A diferença é que a digitação deve atualizar somente os estados locais, mantendo o estado global com dados corretos.
| @@ -0,0 +1,10 @@ | |||
| import styled from 'styled-components' | |||
|
|
|||
| export const DivInput = styled.div` | |||
There was a problem hiding this comment.
Tentar dar nomes mais significativos para styled components. DivInput não tem nenhum significado semântico.
| }) | ||
| } else { | ||
| alert('Por favor, confira sua senha') | ||
| clearInput() |
There was a problem hiding this comment.
Achei que limpar todos os inputs ao ter algum problema não ficou uma experiência de usuário boa.
Errei a confirmação de senha e tive que preencher todos os campos do formulário novamente, sendo que somente a senha estava errada.
Somente mostrar a mensagem de erro seria suficiente nesse caso.
| setRestaurantDetails(res.data.restaurant) | ||
| setProductDetails(res.data.restaurant.products) |
There was a problem hiding this comment.
Aqui, dois estados estão sendo definidos, um com res.data.restaurant, e outro com res.data.restaurant.products.
Acontece que o primeiro (restaurantDetails) vai ter dentro dele os products.
Dessa forma, não é necessário o segundo estado, já que os products poderiam sempre ser acessados como restaurantDetails.
| export const CardItemHistoric = styled.div` | ||
| display:flex; | ||
| flex-direction: column; | ||
| width: 313px; |
There was a problem hiding this comment.
Imagino que a precisão nessa (e em várias outras) medida seja decorrente do layout do Zeplin.
No entanto, raramente as medidas têm a necessidade de serem taaaaao exatas. Ainda mais com os diferentes tamanhos de tela, é bem improvável que uma precisão tão grande faça alguma diferença.
Os layouts servem principalmente para determinar o posicionamento dos elementos, bem como os espaçamentos entre eles. Em geral, os tamanhos em si podem ser definidos com base no tamanho do conteúdo e/ou dos espaçamentos, e não precisam ser definidos diretamente assim.
A exceção fica pra tamanhos de fonte, de margens, paddings, bordas.. Tamanhos que não impactam o posicionamento na tela.
7 participants
No description provided.