- Distinguir entre o que é uma service, componente, model, mock ou utility
- shared/
- components/
- models/
- directives/
- pipes/
- endpoints/
- shared/
- Assim como
component
,service
,module
edirective
possuem prefixo no nome do arquivo, podemos criar novos prefixos adicionais para arquivos comoshared/models/employee.model.ts
- Não utilizar
abstract class
ao menos que precise de um comportamento padrão definido, e uma classe que derive da classe abstrata. - Para representar um contrato de um objeto, utilize
interface
- Não use tipos não-primitivos como
String
,Number
ouBoolean
em momento algum, exceto para definir métodos de extensão. Em vez disso, opte por tipos primitivos. - Todas as propriedades devem seguir estritamente o modelo de negócio, caso contrário, haverá problemas em usar o objeto que vem de uma requisição (por exemplo).
- Não é preciso colocar o prefixo “ViewModel” ou “DTO” numa interface nem o sufixo I
- Nem todos contratos seguem esse padrão
- Conceito de view model ou DTO não existe no Typescript
- Não defina todos atributos como
any
, use os tipos apropriados - Modificadores de acesso não seguem modelo de negócio:
- Definir o que é
readonly
(não confundir comprivate
)
- Definir o que é
- ;
- Usar
any
mesmo quando se sabe o tipo de algo invalida o motivo de usar Typescript - Sempre colocar tipo de retorno, mesmo que seja
void
- Inutiliza plugins IntelliSense
DataService
foi criado para eliminar essa duplicação de código- Não precisa declarar uma nova promise
- Não é preciso lidar com erros (catch)
- Rotas (services), arrays etc não utilizam
const
type Endpoint = Record<string, string>;
namespace HR {
export {
base: '',
employee_contracts: '/api/v1/employee/contracts'
} as Endpoint;
};
namespace Timesheet {
export {
base: ''
} as Endpoint;
};