Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Wiki Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Sem Barreiras
  • WikiWiki
  • Wiki
  • frontend

frontend · Changes

Page history
Update frontend and configuracao authored Mar 18, 2024 by Pablo Miguel Chong Alles's avatar Pablo Miguel Chong Alles
Show whitespace changes
Inline Side-by-side
frontend.md
View page @ c08c1f4b
......@@ -17,7 +17,7 @@ Esta página centraliza informações sobre o [repositório Frontend do projeto
## Organização do repositório
WIP
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:
......@@ -39,14 +39,59 @@ Diante disso, os pacotes do projeto estão divididos da forma abaixo:
## Padrões de código
TBD
Com intuito de manter legibilidade e consistência no código a seguir estão algumas padronizações definidas.
### Nomenclatura de funções
### Nomenclatura de funções e variáveis
### Nomenclatura de 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 :heavy_check_mark:
- Variable_Example :x:
- Variableexample :x:
- VariableExample :x:
### 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 é X componente?}Component.js`. Por exemplo:
- InputTextComponent.js :heavy_check_mark:
- Input_Text_Component.js :x:
- Inputtextcomponent.js :x:
- inputTextComponent.js :x:
### Nomenclatura de telas
Telas 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 da tela deve seguir o padrão `{O que é X tela?}Screen.js`. Por exemplo:
- CreateAccountScreen.js :heavy_check_mark:
- Create_Account_Screen :x:
- Createaccountscreen :x:
- createAccountScreen :x:
### 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:
```
/**
* {Breve descrição do que seu componente/tela faz/é}
*
* @param {nome_parametro_1} {Descrição do que aquele parâmetro faz/setta}
* @example <ComponentExample
* text={"teste"}
* /> <------------- Aqui um exemplo de uso do componente/tela
*/
```
Abaixo é demonstrado um exemplo com o ComponentExample:
```
/**
* Componente de modelo que cria um texto
*
* @param text Texto principal do componente
* @example <ComponentExample
* text={"teste"}
* />
*/
```
\ No newline at end of file
Clone repository
  • Banco de Dados
  • Sprint 0
  • Sprint 1
  • Sprint 2
  • Sprint 3
  • Sprint 4
  • arquitetura
  • backend
  • configuracao
  • design_mockups
  • escopo
  • frontend
  • gerencia
  • Home
  • processo
View All Pages