... | @@ -11,14 +11,14 @@ |
... | @@ -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.
|
|
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:
|
|
Primeiramente, garanta que os seguintes aplicativos estão instalados corretamente em sua máquina:
|
|
- Git - https://git-scm.com/downloads
|
|
- Git - https://git-scm.com/downloads
|
|
- Node - https://nodejs.org/en/
|
|
- Node - https://nodejs.org/en/
|
|
- VsCode - https://code.visualstudio.com/Download (Ou outra IDE para desenvolvimento)
|
|
- 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):
|
|
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 |
... | @@ -35,12 +35,136 @@ code --install-extension ms-vscode.vscode-typescript-next |
|
code --install-extension yoavbls.pretty-ts-errors
|
|
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
|
|
- 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:
|
|
- https://docs.nestjs.com/ |
|
|
|
\ No newline at end of file |
|
```
|
|
|
|
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 |