Package | Tipo |
---|---|
Typescript | Linguagem |
React + React DOM | Componentes |
React Router | Roteamento |
Storybook | Design System |
Material-UI | Design System |
Testing Library + Jest | Testes |
Apollo | Networking |
ESLint | Linting |
Extra | |
Yup | Formulários |
Formik | Formulários |
Axios (caso precise de compatibilidade) | Networking |
Usar tipagem sempre para estruturas de dados (type / typedef / interface), artigo interessante com algumas dicas do uso de typescript principalmente com react:
10++ TypeScript Pro tips/patterns with (or without) React
Para não haver confusão na nomeclatura de arquivos sugiro unificarmos todos a terem sempre a mesma regra, independente do seu propósito, uma sugestão é usar kebab-case
ou snake_case
.
Um módulo em TS ou JS pode existir para alguns propósitos:
- Componente (elementos de ui, props e estado)
- Página (cosumo dos componentes e integração com outros tipos de módulos)
- Estrutura de dado (tipo complexo e reutilizável entre módulos)
- Feature (módulos e submódulos que lidam com uma parte específica da aplicação como http, parsing, graphql, etc)
Partindo disso, acredito que, baseado no caso de uso da Xerpa poderiamos aderir uma seguinte estrutura:
src/
shared/ # Componentes compartilhados
pages/
models/ # Definição das estruturas de dados compartilhadas
example-model.ts
...
# Apollo Graphql:
graphql/
graphql.ts # Configuração e gerenciamento do clientes
queries/
example-query.ts
...
# No caso de Redux, duck pattern:
store/
store.ts
reducers/
example-reducer.ts
...
# ../ Demais features para tratar coisas específicas.