Ir para o conteúdo

Desenvolvimento front-end (2024)/Teste/vicgraycloak

Grupo de Usuários Wiki Movimento Brasil

Desenvolvimento front-end

[editar]

Boas-vindas ao teste de conhecimento e aptidão da vaga de Desenvolvimento front-end do projeto Capacity Exchange, coordenado pelo Wiki Movimento Brasil. O teste consistirá em um exercício de criação e documentação de um template para o protótipo do CapX.

Informações importantes

[editar]

Antes de editar esta página, verifique se você está logada(o) na sua conta wiki. Se você tem dúvidas sobre como editar neste ambiente, recomenda-se a leitura desta brochura. Tenha em vista que suas respostas estarão livremente acessíveis, uma vez publicadas no ambiente wiki. Se desejar registrar o conteúdo à medida que realiza a atividade do teste, você pode editar e publicar a página quantas vezes precisar. Apenas tome o cuidado de sua conta estar sempre logada. Não serão aceitas edições realizadas 24 horas após o recebimento do e-mail com o link desta atividade.

Nome de usuário(a)

[editar]
  • vicgraycloak

Exercício

[editar]

O Capacity Exchange é um protótipo recém lançado de uma rede social para a conexão e aprendizado entre pares no Movimento Wikimedia. O projeto é desenvolvido em Python e JavaScript JavaScript. Encontra-se disponível no Toolforge e está parcialmente documentado na Meta-Wikimedia. Utilizando JavaScript, crie o(s) arquivo(s) necessário(s) para apresentar os dados providos neste arquivo JSON (organizations.json), associado com os JSONs complementares (territory.json e type.json) de tal modo que sejam garantidos dinamismo, legibilidade, acessibilidade e usabilidade. Para o layout, dê continuidade a identidade visual aplicada no protótipo, que tem por base o Manual de Identidade Visual. Ao final, documente seu template, descrevendo cada elemento e o motivo de sua escolha. Envie para capxATwmnobrasil.org o nome de usuário/a que utilizou para completar o teste e os arquivos criados para esta resposta. Abaixo, insira a documentação de seu template.

Documentação do Template

[editar]

Para criar o template solicitado, foram desenvolvidos os seguintes componentes e funcionalidades:

1. Componente OrganizationCard

[editar]

Foi criado um componente reutilizável chamado OrganizationCard para exibir as informações de cada organização. Este componente recebe os dados de uma organização como props e renderiza um card com as seguintes informações:

  • Logo da organização (quando disponível)
  • Nome da organização
  • Tipo de organização
  • Acrônimo
  • Território (quando disponível)
  • Links para a página meta e projeto principal (quando disponíveis)

O design do card segue a identidade visual do CapX, utilizando as cores e estilos definidos no Manual de Identidade Visual, com suporte para modo escuro.

2. Componente OrganizationList

[editar]

Este componente é responsável por renderizar a lista de organizações. Ele utiliza o componente OrganizationCard para exibir cada organização individualmente. Além disso, implementa as seguintes funcionalidades: Filtro por tipo de organização Barra de pesquisa para filtrar organizações por nome Layout responsivo utilizando grid para exibir os cards em diferentes tamanhos de tela

3. Componente OrganizationSection

[editar]

Este é o componente principal que agrupa todos os elementos relacionados às organizações. Ele inclui:

  • Título da seção
  • Componente OrganizationList
  • Lógica para carregar e processar os dados dos arquivos JSON

4. Integração com Tailwind CSS

[editar]

Para garantir a consistência visual e facilitar o desenvolvimento responsivo, foi utilizado o framework Tailwind CSS. Isso permitiu:

  • Aplicação rápida de estilos consistentes
  • Implementação fácil de layout responsivo
  • Customização de cores e estilos de acordo com a identidade visual do CapX

5. Internacionalização

[editar]

Adicionamos strings de texto nos arquivos JSON separados para os idiomas inglês e português.

6. Acessibilidade

[editar]

Foram adicionados atributos ARIA e estrutura semântica adequada para melhorar a acessibilidade do template. Isso inclui:

  • Uso apropriado de tags semânticas
  • Atributos alt para imagens
  • Rótulos adequados para elementos interativos

7. Usabilidade

[editar]

Para melhorar a usabilidade, foram implementados: Filtros intuitivos para tipo de organização Barra de pesquisa para encontrar organizações rapidamente Layout responsivo para uma boa experiência em diferentes dispositivos. Suporte para modo escuro.

8. Dinamismo

[editar]

O template foi desenvolvido de forma a ser totalmente dinâmico: Os dados são carregados de arquivos JSON externos. A lista de organizações é gerada dinamicamente com base nos dados carregados. Os filtros e a pesquisa atualizam a lista em tempo real. Criamos um arquivo `organizations`, na pasta `api`, com as funções de fetch que acessam as rotas definidas da API Django, responsáveis pelos dados consumidos nos componentes. Infelizmente, não conseguimos terminar a implementação devido a erro de não autorização com os tokens providos. Dessa forma, mantivemos a implementação, consultando arquivos estáticos.

9. Storybook

[editar]

Foram criadas stories no Storybook para os componentes principais, permitindo:

  • Visualização isolada dos componentes
  • Testes de diferentes estados e props
  • Documentação interativa dos componentes

10. Readme

[editar]

O arquivo readme do projeto foi editado para conter instruções de como executar o Storybook localmente para ver os componentes criados e testá-los com estados diferentes.

11. Desafios e sugestões de melhoria

[editar]
  • Os arquivos de imagens das organizações têm formatos e proporções diferentes, o que leva a uma falta de padrão na UI. Organizações com imagens maiores podem ser consideradas mais importantes do que as com imagens menores. O ideal seria trabalhar com imagens de mesmas proporções.
  • O projeto não possui testes funcionais o que pode levar a componentes quebrados, dependendo dos dados que forem recebidos da API.
  • O uso de javascript sem tipagem, seja por JSDocs ou Typescript, não é aconselhável para essa aplicação, visto que os componentes esperam receber propriedades com tipos definidos. Um componente sem tipagem correta pode quebrar caso a propriedade venha undefined, null ou algum outro tipo inesperado.