Frontend

Esta página centraliza informações sobre o repositório Frontend do projeto Point Tils.

Sumário

• Escolha de tecnologias
• Organização do repositório
• Padrões de código
• Acessibilidade

Escolha de tecnologias

A definição da tecnologia para o desenvolvimento do frontend do projeto foi realizada de forma colaborativa, por meio de uma votação entre os membros da equipe. O critério adotado levou em consideração a familiaridade prévia dos desenvolvedores com as ferramentas, buscando otimizar a curva de aprendizado e acelerar a fase inicial de desenvolvimento.

Assim, a equipe optou por utilizar React Native com TypeScript, principalmente pelos seguintes fatores:

• Familiaridade da equipe: a maioria dos membros já possuía experiência com React/React Native, o que reduziu a necessidade de treinamentos extensivos.

• Robustez do TypeScript: o uso de TypeScript traz benefícios como tipagem estática, maior confiabilidade do código e facilidade de manutenção.

• Comunidade e ecossistema: a tecnologia conta com uma comunidade ampla, vasta documentação e bibliotecas consolidadas, o que facilita a resolução de problemas e a incorporação de novas funcionalidades.

Essa decisão refletiu um equilíbrio entre praticidade, produtividade e qualidade do software, garantindo que a equipe pudesse se concentrar mais na implementação das funcionalidades e menos em aprender do zero uma nova tecnologia.

Organização do repositório

O projeto React Native do repositório de Frontend está organizado seguindo um padrão de componentização. Essa abordagem envolve a divisão da interface do usuário em componentes modulares e reutilizáveis, que são então compostos para formar as diversas telas ou páginas do aplicativo. Dessa forma, tendo um componente podemos passar parametros com o que quisermos ter e trabalhar na tela. As telas tem um comportamento semelhante, dado que elas são chamadas a partir de um arquivo que irá realizar o controle de roteamento do usuário passando as informações necessárias para que se possa executar as funcionalidades da aplicação.

Diante disso, os pacotes do projeto estão divididos da forma abaixo:

• 📁 app/: Telas e layouts principais.

• 📁 src/

  • 📁 assets/: Recursos estáticos como imagens e fontes.
  • 📁 components/: Componentes reutilizáveis, incluindo:
    • 📁 ui/: Componentes específicos do GlueStack.
  • 📁 constants/: Constantes globais, como cores e strings.
  • 📁 contexts/: Providers e contextos globais.
  • 📁 hooks/: Hooks compartilhados para lógica reutilizável.
  • 📁 types/: Definições de tipos TypeScript.

  +: Arquivos de configuração do projeto, como tailwind.config.js, eslint.config.js, e tsconfig.json

Padrões de código

Com intuito de manter legibilidade e consistência no código a seguir estão algumas padronizações definidas.

Nomenclatura de funções e variáveis

Funções do projeto devem ser nomeadas em inglês e seguir o padrão camelCase, ou seja, devem iniciar com letra maiúscula e cada palavra ou abreviatura no meio da frase também deve iniciar com letra maiúscula. Por exemplo:

• variableExample ✔
• Variable_Example ❌
• Variableexample ❌
• VariableExample ❌

Nomenclatura de componentes

Componentes do projeto devem ser nomeadas em inglês e seguir o padrão PascalCase, ou seja, devem iniciar com letra maiúscula e cada palavra ou abreviatura no meio da frase também deve iniciar com letra maiúscula. Além disso, o nome do arquivo e da função de retorno do componente deve seguir o padrão {O que é o componente?}.tsx. Por exemplo:

• InputText.tsx ✔
• Input_Text_Component.tsx ❌
• Inputtext.tsx ❌
• inputText.tsx ❌

Nomenclatura de telas

Arquivos de telas do projeto devem ser nomeadas em inglês e seguir o padrão snake_case, ou seja, devem iniciar com letra minúscula e cada palavra devem ser separadas por _. Além disso, a função de retorno da tela deve seguir o padrão PascalCase: {O que é a tela?}Screen.tsx. Por exemplo:

Documentação de componentes e telas

Para que outras pessoas que forem olhar como utilizar seu componente ou tela é importante que elas entendam o que cada parâmetro quer dizer. Com isso, vem a importância da documentação de parâmetros de componentes e telas a fim de proporcionar uma compreensão rápida e evitar erros. Embora o nome da variável muitas vezes deixe explícito o que ela faz, outras vezes pode ser que não esteja tão claro assim. Dessa forma, isso leva a um custo de a pessoa ter de analisar o código para entender o que X valor significa.

Assim, para cada componente e tela, visto que componentes serão chamados múltiplas vezes e telas serão chamadas no roteamento, é importante seguir o seguinte padrão de documentação no começo do arquivo .tsx de cada um:

• breve descrição do que o componente/tela é responsável
• parametros do componente/tela e descrição do que eles representam
• exemplo de chamada do componente/tela

Veja esse exmplo:

/**
 * Componente de modelo que cria um texto
 *
 * @param text       Texto principal do componente
 * @example          <ComponentExample text={"teste"} />
 */

Acessibilidade

TODO