eduardomcf / pnnd Goto Github PK

Achei interessante a ideia, e fiz algumas anotações do que poderia ser feito:

• Em rating, ficaria legal colocar algumas ⭐ estilo para tornar mais atrativo ao usuário.
• Quanto à organização dos componentes, como cada um possui um arquivo CSS específico, eu colocaria cada um dentro de uma pasta, para facilitar.
• Quanto à navegabilidade, a navegação por tabs não me parece tão adequada, eu consideraria a utilização de botões no header ou em algum outro lugar de fácil acesso que tornasse possível o cadastro de imagens, que seria a tela 3, e faria com que cada imagem se tornasse um link que permitisse acesso a tela 2.

Oi Eduardo, sugiro que você crie controllers para separar a lógica das rotas. Dá uma olhada nesse link.

Ao invés de recuperar os elementos com document.getElement, poderia utilizar as próprias funções do React como:

• Adicionar atributo onClick no button de id "openbtn"
• Adicionar atributo onClick na tag A de id "closebtn"

Os dois poderiam mudar um estado do componente que determinaria quando a navbar estaria aberta ou fechada e esses botões manipulariam este valor.

Já para a definição da estilização dinâmica, tem outros meios de contornar isso como o uso do pacote classNames. Porém para resolver de uma forma mais simples, poderia usar o atributo styles dentro da tag html e passar um objeto...

Exemplo:
const sidebarWidth = openedSidebar ? "250px" : "0px"

Acredito que essa seria uma forma mais simples usando React. Se puder ver uma forma de não precisar manipular a div root ao modificar os estilos da NavBar seria ótimo.

Boa tarde, observando a estrutura do folder components, vi que os arquivos dos componentes não estão encapsulados em subfolders, isso poderia ser feito para melhorar a organização do código tanto para quem escreve como para outras pessoas que tentam entender o projeto, principalmente para quando aumentar a quantidade de componentes.

Eu amei o projeto e acho que pode ser usado para auxiliar os professores com os alunos com deficiência visual. Só uma coisa que percebi é que a constante Annotations já tem alguns dados, onde seus atributos estão na sequência: id, tumb, tags, rating. Mas quando é feito uma requisição POST os atributos são adicionados nesse sequência: id, tags, rating, tumb.

Como sugestão, penso que seria interessante ter no README instruções que mostrassem como executar o backend e o frontend localmente.

As cores utilizadas prejudicam na experiência do usuário (deixando claro que não sei se as cores serão essas mesmas), por exemplo, na rota raiz / temos o header de verde e abaixo a parte da lista em branco, alterando para a rota /annotate a maior parte da tela é vermelha e ao voltar para a tela de listagem a mudança de cores é um pouco brusca prejudicando a experiência do usuário, optaria por tons mais semelhantes.

Opa, excelente projeto.
Sobre as chamadas ao back, acredito que seria interessante definir a rota da API (http://localhost:3006) em um arquivo separado, como em um .env ou até um config.js, por exemplo. Essa modularização facilitaria bastante a alteração em futuras versões do projeto, já que esta informação seria centralizada, permitindo assim, que a alteração em um único lugar, afete todas as partes do código que chamadas realizem chamadas a API.

Minha sugestão seria criar uma pasta para conter arquivos que encapsulam as chamadas para a API, dessa forma facilitando a reutilização dessas chamadas

Testar os componentes é importante para evitar bugs no seu sistema, então sugiro que você os faça.