Configuração.md

@@ -11,14 +11,14 @@
 
 Esta seção apresentará todas as configurações necessárias dos ambientes do Front-end, Back-end e Banco de Dados, permitindo a execução do projeto completo localmente.
 
-### Pré-Requisitos
+## Pré-Requisitos
 
 Primeiramente, garanta que os seguintes aplicativos estão instalados corretamente em sua máquina:
 - Git - https://git-scm.com/downloads
 - Node - https://nodejs.org/en/
 - VsCode - https://code.visualstudio.com/Download (Ou outra IDE para desenvolvimento)
 
-### Extensões Recomendadas
+## Extensões Recomendadas
 
 Após instalar o VsCode, abrir um terminal nele e rodar os seguintes comandos (Copie e cole):
 
@@ -35,12 +35,136 @@ code --install-extension ms-vscode.vscode-typescript-next
 code --install-extension yoavbls.pretty-ts-errors
 ```
 
-### Frontend
+## Frontend
 
-Para o fronted do projeto, utilizaremos a linguagem o NEXT:
+Para o fronted do projeto, utilizaremos a linguagem Next.js + Tailwind CSS + TypeScript + ESLint + Prettier
 - https://nextjs.org/docs
 
-### Backend
+### Rodando a aplicação:
 
-Para o backend do projeto, utilizaremos a linguagem o NestJS:
+Primeiro, execute o comando abaixo para rodar a aplicação:
+
+```
+npm run dev
+```
+
+Abra o link [text](http://localhost:3000) no seu navegador para ver os resultados.
+
+### Nomenclatura de arquivos
+
+- Arquivos de páginas devem ser nomeados em kebab-case (exemplo: `src/app/my-page/page.tsx`)
+- Arquivos de componentes devem ser nomeados em PascalCase (exemplo: `src/components/MyComponent/MyComponent.tsx`)
+- Arquivos de componentes de UI devem ser nomeados em PascalCase (exemplo: `src/components/ui/MyComponent.tsx`)
+
+### Desenvolvimento
+
+- *Cores*: Utilizar as varívais de estilização do tailwind ( exemplos de uso em `src/app/examples` )
+- *Tipografia*: Utilizar componente de Text do `src/components/ui/Text.tsx` ( exemplos de uso em `src/app/examples` )
+- *Dicionário*: Strings estáticas devem ser armazenadas em um arquivo de dicionário `public/dictionaries`. Neste arquvio contém dois idiomas ( pt-Br e en-Us ), as strings devem ser armazenadas em ambos os idiomas, sendo agrupadas por alguma tag que identifique a que estão relacionadas. Por exemplo: Strings relacionadas a tela "Profile", nos arquvios de idioma deve ser criado um objeto "Profile": { 'string-variable': "traducao" } ( Profile em PascalCase ) que vai conter todas as strings presentes na tela "Profile". Esta tag deve ser utilizada na importação do hook de tradução `const t = useTranslation('Profile')` e as strings devem ser acessadas através do `t('string-variable')` ( string-variable em kebab-case )
+- *Estilização*: Utilizar o tailwind para estilização de componentes `https://tailwindcss.com/docs/` ( No menu da lateral esquerda do site você encontra a documentação de cada classe: LAYOUT | FLEXBOX & GRID | SPACING | SIZING | BACKGROUNDS | BORDERS | EFFECTS | FILTERS | TABLES | TRANSITION & ANIMATION | TRANSFORMS | INTERACTIVITY | SVG | ACESSIBILITY )
+- *Código*: Desenvolver o código em inglês
+- *Formatação*: Antes de commitar rodar `npm run lint -- --fix` para corrigir os erros de formatação, erros no código apontados pelo eslint devem ser corrigidos na mão, ecitar o uso do `// eslint-disable-next-line` para ignorar os erros
+
+### Páginas
+
+- Arquivos de páginas devem ser criados na pasta `src/app/<page-name>/page.tsx` ( page-name em kebab-case )
+- Functions de página devem ser nomeadas com a primeira letra maiúscula ( PascalCase )
+- Páginas NÃO devem ser client components ( não devem ter `use client` ), a menos que seja necessário
+- Paginas de exemplo de uso de componente devem ser criadas em `src/app/examples/<page-name>/page.tsx` ( page-name em kebab-case; Idealmente não devem ser comitadas )
+
+### Componentes
+
+- Arquivos de componentes devem ser criados na pasta `src/components/<ComponentName>/` ( ComponentName em PascalCase )
+- Rota completa: `src/components/<ComponentName>/<ComponentName>.tsx` ( ComponentName em PascalCase )
+- Arquivos de componentes devem ser nomeados com a primeira letra maiúscula ( PascalCase )
+- Arquivos de componentes devem ser nomeados com o mesmo nome da pasta
+- Arquivos relacionados a um componente devem ser criados na mesma pasta ( caso este não seja utilizado em outros componentes )
+
+### Componentes de UI
+
+- Componentes de UI são componentes que não possuem lógica de negócio, apenas estilização e renderização de dados
+- Componentes de UI devem ser criados na pasta `src/components/ui/`
+- Rota completa: `src/components/ui/<ComponentName>.tsx` ( ComponentName em PascalCase )
+- Arquivos de componentes de UI devem ser o mais genérico possivel
+- Arquivos de componentes de UI devem ser nomeados com a primeira letra maiúscula
+
+### Component x Function/Arrow Function
+
+- Componentes devem ser criados como function components ( export default function ) `ComponentName em PascalCase`
+- Funções são criadas dentro de componentes, não devem ser exportadas ( const = () => { ... } ) `functionName em camelCase`
+
+## Backend
+
+Para o backend do projeto, utilizaremos a linguagem  Nest.js
 - https://docs.nestjs.com/
+
+### Banco de Dados
+
+Crie e execute o container do banco de dados usando os comandos abaixo:
+
+```
+docker build -t creativeflow-postgres .
+
+docker run --env-file ./docker.env --name creativeflow-db -p 5432:5432 creativeflow-postgres
+```
+
+Após, defina a conexão com o backend:
+
+```
+.env
+
+DATABASE_URL="postgresql://<user>:<password>@localhost:5432/creativeflow"
+
+# Set <user> and <password> with the values provided inside 'docker.env'
+```
+
+Execute o prisma:
+
+```
+# Creates database structure
+npx prisma migrate dev --name init
+
+# Verify conenction
+npx prisma db pull
+
+#Database seeding
+npm run prisma:seed
+
+#Reset database
+npm run prisma:reset
+
+#Database update
+npm run prisma:update
+```
+
+### Nomenclatura de arquivos
+
+- Diretórios (pastas) devem ser nomeados em `camelCase` (exemplo: `src/controllers`)
+- Todos os arquivos devem ser nomeados em `camelCase` (exemplo: `src/controllers/userExercise.controller.ts`)
+- Todos os arquivos devem ser nomeados baseados nas entidades dos mesmos no arquivo `schema.prisma` seguidos por sua função arquitetural (exemplo: O arquivo de *service* da entidade *User* deve ser nomeado `user.service.ts`)
+- Arquivos de DTO devem, além de seguir os padrões anteriores, possuir o sufixo `DTO` (exemplo: o DTO de recebido de um exercício de usuário, deve ser nomeado `userExerciseDTO.dto.ts`)
+- Arquivos de teste devem estar dentro de um diretório `tests` dentro do diretório arquitetural correspondente e devem ter a denominação `spec` ( exemplo: `src/controllers/tests/userExercise.controller.spec.ts` )
+
+### Desenvolvimento
+
+- *Rotas*:
+  - Objetos Controllers devem ser nomeados em `PascalCase` (exemplo: `export class UserExerciseController`)
+  - Controllers devem ter o *decorator* `@ApiBearerAuth('Authorization')` em seu cabeçalho isso fará a autenticação do usuário com o token JWT se aplicar a todas as rotas dentro daquele controller
+  - Rotas públicas devem ter o *decorator* `@IsPublic()`, isso fará com que o token JWT não seja necessário para acessar a rota.
+  - Na declaração da rota, o NestJS exige um decorator para o tipo de rota (GET, POST, DELETE, etc) e o caminho da rota. O caminho deve ser nomeado em `kebab-case` (exemplo: `@Get('/user-exercise')`)
+  - Em casos que a rota tenha um único parâmetro, o mesmo deve ser nomeado em `kebab-case` e passado diretamente no URL(exemplo: `@Get('/user-exercise/:id')` e nos parâmetros da função `getUserExercise(@Param('id') id: string)`)
+  - Em casos que a rota tenha mais de um parâmetro, deve ser utilizado um DTO personalizado para aquele caso
+  - Todos os métodos de um *controller* devem ter seus parâmetros e seus retornos tipados, mesmo que o retorno seja `void`(exemplo: `getUserExercise(@Param('id') id: string): Promise<UserExerciseDTO>`)
+- *Data Transfer Objects (DTOs)*:
+  - DTOs devem ter apenas os campos necessários para a operação que estão realizando e devem ter decorators do `class-validator` para validação dos dados recebidos. Exemplo: `@IsString()`, `@IsEmail()`, `@IsNotEmpty()`, `@IsOptional()`, `@IsBoolean()`, `@IsNumber()`, `@IsDate()`, etc.
+  - DTOs devem ser nomeados em `PascalCase` e devem ter o sufixo `DTO` (exemplo: `UserExerciseDTO.dto.ts`)
+- *Serivces*:
+  - Objetos Service devem ser nomeados em `PascalCase` (exemplo: `export class UserExerciseService`)
+  - Services devem ter o decorator `@Injectable()` em seu cabeçalho
+  - Todos os métodos de um *service* devem ter seus parâmetros e seus retornos tipados, mesmo que o retorno seja `void`(exemplo: `getUserExercise(id: string): Promise<UserExerciseDTO>`)
+  - Erros esperados (como usuário não estar no BD) devem ser lançados com o `HttpException` do NestJS, passando o código de erro e a mensagem de erro. Exemplo: `throw new HttpException('User not found', HttpStatus.NOT_FOUND)`
+- *Mappers*:
+  - Mappers devem ser utilizados para a criação de linhas nas tabelas do banco de dados (veja exemplo no arquivo `src/mappers/user.mapper.ts`)
+  - Mappers devem ser nomeados em `PascalCase` e devem ter o sufixo `Mapper` (exemplo: `UserExerciseMapper.mapper.ts`)
+- *Código*: Desenvolver o código em inglês
+- *Formatação*: Antes de commitar rodar `npm run lint -- --fix` para corrigir os erros de formatação, erros no código apontados pelo eslint devem ser corrigidos na mão, evitar o uso do `// eslint-disable-next-line` para ignorar os erros
\ No newline at end of file