docs: localize navigation tabs and groups for supported locales (#15811)
This commit is contained in:
Abdul Rahman
+26
-26
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Arquitetura de Pastas
|
||||
info: Uma visão detalhada da nossa arquitetura de pastas
|
||||
info: Um olhar detalhado sobre nossa arquitetura de pastas
|
||||
image: /images/user-guide/fields/field.png
|
||||
---
|
||||
|
||||
@@ -8,9 +8,9 @@ image: /images/user-guide/fields/field.png
|
||||
<img src="/images/user-guide/fields/field.png" alt="Header" />
|
||||
</Frame>
|
||||
|
||||
Neste guia, você explorará os detalhes da estrutura de diretórios do projeto e como ela contribui para a organização e manutenção do Twenty.
|
||||
Neste guia, você explorará os detalhes da estrutura de diretórios do projeto e como isso contribui para a organização e manutenção do Twenty.
|
||||
|
||||
Ao seguir esta convenção de arquitetura de pastas, é mais fácil encontrar os arquivos relacionados a recursos específicos e garantir que o aplicativo seja escalável e de fácil manutenção.
|
||||
Seguindo esta convenção de arquitetura de pastas, é mais fácil encontrar os arquivos relacionados a funcionalidades específicas e garantir que a aplicação seja escalável e sustentável.
|
||||
|
||||
```
|
||||
front
|
||||
@@ -29,12 +29,12 @@ front
|
||||
|
||||
## Páginas
|
||||
|
||||
Inclui os componentes de nível superior definidos pelas rotas da aplicação. Eles importam mais componentes de baixo nível da pasta de módulos (mais detalhes abaixo).
|
||||
Inclui os componentes de nível superior definidos pelas rotas da aplicação. Eles importam componentes mais de baixo nível da pasta de módulos (mais detalhes abaixo).
|
||||
|
||||
## Módulos
|
||||
|
||||
Cada módulo representa um recurso ou um grupo de recursos, compreendendo seus componentes específicos, estados e lógica operacional.
|
||||
Todos devem seguir a estrutura abaixo. Você pode aninhar módulos dentro de módulos (referido como submódulos) e as mesmas regras se aplicarão.
|
||||
Cada módulo representa uma funcionalidade ou um grupo de funcionalidades, compreendendo seus componentes específicos, estados e lógica operacional.
|
||||
Todos devem seguir a estrutura abaixo. Você pode aninhar módulos dentro de módulos (referidos como submódulos) e as mesmas regras se aplicarão.
|
||||
|
||||
```
|
||||
module1
|
||||
@@ -57,58 +57,58 @@ module1
|
||||
|
||||
### Contextos
|
||||
|
||||
Um contexto é uma forma de passar dados através da árvore de componentes sem precisar passar props manualmente em cada nível.
|
||||
Um contexto é uma maneira de passar dados através da árvore de componentes sem ter que passar propriedades manualmente em cada nível.
|
||||
|
||||
See [React Context](https://react.dev/reference/react#context-hooks) for more details.
|
||||
Veja [React Context](https://react.dev/reference/react#context-hooks) para mais detalhes.
|
||||
|
||||
### GraphQL
|
||||
### "GraphQL"
|
||||
|
||||
Inclui fragmentos, consultas e mutações.
|
||||
|
||||
See [GraphQL](https://graphql.org/learn/) for more details.
|
||||
Veja [GraphQL](https://graphql.org/learn/) para mais detalhes.
|
||||
|
||||
- Fragmentos
|
||||
|
||||
Um fragmento é uma parte reutilizável de uma consulta, que pode ser usada em diferentes lugares. Ao usar fragmentos, é mais fácil evitar duplicação de código.
|
||||
Um fragmento é uma parte reutilizável de uma consulta, que você pode usar em diferentes lugares. Usando fragmentos, é mais fácil evitar duplicar código.
|
||||
|
||||
See [GraphQL Fragments](https://graphql.org/learn/queries/#fragments) for more details.
|
||||
Veja [GraphQL Fragments](https://graphql.org/learn/queries/#fragments) para mais detalhes.
|
||||
|
||||
- Consultas
|
||||
|
||||
See [GraphQL Queries](https://graphql.org/learn/queries/) for more details.
|
||||
Veja [GraphQL Queries](https://graphql.org/learn/queries/) para mais detalhes.
|
||||
|
||||
- Mutações
|
||||
|
||||
See [GraphQL Mutations](https://graphql.org/learn/queries/#mutations) for more details.
|
||||
Veja [GraphQL Mutations](https://graphql.org/learn/queries/#mutations) para mais detalhes.
|
||||
|
||||
### Ganchos
|
||||
### Hooks
|
||||
|
||||
See [Hooks](https://react.dev/learn/reusing-logic-with-custom-hooks) for more details.
|
||||
Veja [Hooks](https://react.dev/learn/reusing-logic-with-custom-hooks) para mais detalhes.
|
||||
|
||||
### Estados
|
||||
|
||||
Contém a lógica de gerenciamento de estado. [RecoilJS](https://recoiljs.org) trata disso.
|
||||
Contém a lógica de gerenciamento de estado. [RecoilJS](https://recoiljs.org) lida com isso.
|
||||
|
||||
- Selectors: See [RecoilJS Selectors](https://recoiljs.org/docs/basic-tutorial/selectors) for more details.
|
||||
- Seletores: Veja [RecoilJS Selectors](https://recoiljs.org/docs/basic-tutorial/selectors) para mais detalhes.
|
||||
|
||||
O gerenciamento de estado interno do React ainda controla o estado dentro de um componente.
|
||||
O gerenciamento de estado embutido do React ainda lida com o estado dentro de um componente.
|
||||
|
||||
### Utils
|
||||
### Utilitários
|
||||
|
||||
Deve apenas conter funções puras reutilizáveis. Caso contrário, crie ganchos personalizados na pasta `hooks`.
|
||||
Deve conter apenas funções puras reutilizáveis. Caso contrário, crie hooks personalizados na pasta `hooks`.
|
||||
|
||||
## UI
|
||||
|
||||
Contém todos os componentes de UI reutilizáveis utilizados na aplicação.
|
||||
Contém todos os componentes reutilizáveis de UI usados na aplicação.
|
||||
|
||||
Esta pasta pode conter subpastas, como `data`, `display`, `feedback` e `input` para tipos específicos de componentes. Cada componente deve ser autônomo e reutilizável, para que você possa usá-lo em diferentes partes da aplicação.
|
||||
Esta pasta pode conter subpastas, como `data`, `display`, `feedback` e `input` para tipos específicos de componentes. Cada componente deve ser autocontido e reutilizável, de modo que você possa usá-lo em diferentes partes da aplicação.
|
||||
|
||||
Ao separar os componentes de UI dos outros componentes na pasta `modules`, fica mais fácil manter um design consistente e fazer mudanças na UI sem afetar outras partes (lógica de negócios) do código.
|
||||
Ao separar os componentes de UI dos outros componentes na pasta `modules`, é mais fácil manter um design consistente e fazer alterações na UI sem afetar outras partes (lógica de negócios) do código.
|
||||
|
||||
## Interface e dependências
|
||||
|
||||
Você pode importar código de outros módulos de qualquer módulo, exceto da pasta `ui`. Isso manterá seu código fácil de testar.
|
||||
Você pode importar outros códigos de módulo de qualquer módulo, exceto para a pasta `ui`. Isso manterá seu código fácil de testar.
|
||||
|
||||
### Interno
|
||||
|
||||
Cada parte (ganchos, estados, ...) de um módulo pode ter uma pasta `interno`, que contém partes usadas apenas dentro do módulo.
|
||||
Cada parte (hooks, estados, ...) de um módulo pode ter uma pasta `internal`, que contém partes que são usadas apenas dentro do módulo.
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Comandos de Frontend
|
||||
title: Comandos do Frontend
|
||||
image: /images/user-guide/create-workspace/workspace-cover.png
|
||||
---
|
||||
|
||||
@@ -7,15 +7,15 @@ image: /images/user-guide/create-workspace/workspace-cover.png
|
||||
<img src="/images/user-guide/create-workspace/workspace-cover.png" alt="Header" />
|
||||
</Frame>
|
||||
|
||||
## Comandos úteis
|
||||
## Comandos Úteis
|
||||
|
||||
### Iniciando o app
|
||||
### Iniciando o aplicativo
|
||||
|
||||
```bash
|
||||
npx nx start twenty-front
|
||||
```
|
||||
|
||||
### Regenerate graphql schema based on API graphql schema
|
||||
### Regenerar esquema GraphQL baseado no esquema de API GraphQL
|
||||
|
||||
```bash
|
||||
npx nx run twenty-front:graphql:generate --configuration=metadata
|
||||
@@ -49,11 +49,11 @@ npx nx run twenty-front:storybook:test # run tests # (needs yarn storybook:serve
|
||||
npx nx run twenty-front:storybook:coverage # (needs yarn storybook:serve:dev to be running)
|
||||
```
|
||||
|
||||
## Pilha Tecnológica
|
||||
## Pilha de Tecnologias
|
||||
|
||||
O projeto tem uma pilha limpa e simples, com código boilerplate mínimo.
|
||||
O projeto possui uma pilha limpa e simples, com pouco código boilerplate.
|
||||
|
||||
**App**
|
||||
**Aplicativo**
|
||||
|
||||
- [React](https://react.dev/)
|
||||
- [Apollo](https://www.apollographql.com/docs/)
|
||||
@@ -76,21 +76,21 @@ O projeto tem uma pilha limpa e simples, com código boilerplate mínimo.
|
||||
|
||||
### Roteamento
|
||||
|
||||
[React Router](https://reactrouter.com/) lida com o roteamento.
|
||||
[React Router](https://reactrouter.com/) gerencia o roteamento.
|
||||
|
||||
Para evitar [re-renderizações](/l/pt/developers/frontend-development/best-practices-front#managing-re-renders) desnecessárias, toda a lógica de roteamento está em um `useEffect` em `PageChangeEffect`.
|
||||
Para evitar [re-renderizações](/l/pt/developers/frontend-development/best-practices-front#managing-re-renders) desnecessárias, toda a lógica de roteamento está em um `useEffect` no `PageChangeEffect`.
|
||||
|
||||
### Gerenciamento de Estado
|
||||
|
||||
[Recoil](https://recoiljs.org/docs/introduction/core-concepts) lida com o gerenciamento de estado.
|
||||
[Recoil](https://recoiljs.org/docs/introduction/core-concepts) gerencia o estado.
|
||||
|
||||
Veja [melhores práticas](/l/pt/developers/frontend-development/best-practices-front#state-management) para mais informações sobre o gerenciamento de estado.
|
||||
Veja [melhores práticas](/l/pt/developers/frontend-development/best-practices-front#state-management) para mais informações sobre gerenciamento de estado.
|
||||
|
||||
## Testes
|
||||
|
||||
[Jest](https://jestjs.io/) serve como ferramenta para testes unitários enquanto [Storybook](https://storybook.js.org/) é para testes de componentes.
|
||||
[Jest](https://jestjs.io/) serve como ferramenta para testes unitários enquanto [Storybook](https://storybook.js.org/) para teste de componentes.
|
||||
|
||||
Jest é utilizado principalmente para testar funções utilitárias, não os próprios componentes.
|
||||
Jest é principalmente para testar funções utilitárias, e não os componentes em si.
|
||||
|
||||
Storybook destina-se a testar o comportamento de componentes isolados, bem como a exibir o sistema de design.
|
||||
Storybook é para testar o comportamento de componentes isolados, bem como exibir o sistema de design.
|
||||
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Atalhos de Teclado
|
||||
title: Teclas de atalho
|
||||
image: /images/user-guide/table-views/table.png
|
||||
---
|
||||
|
||||
@@ -9,37 +9,37 @@ image: /images/user-guide/table-views/table.png
|
||||
|
||||
## Introdução
|
||||
|
||||
When you need to listen to a hotkey, you would normally use the `onKeyDown` event listener.
|
||||
Quando você precisa ouvir uma tecla de atalho, normalmente usaria o listener de evento `onKeyDown`.
|
||||
|
||||
No `twenty-front` no entanto, você pode ter conflitos entre as mesmas teclas de atalho que são usadas em diferentes componentes, montados ao mesmo tempo.
|
||||
No entanto, em `twenty-front`, você pode ter conflitos entre as mesmas teclas de atalho que são usadas em diferentes componentes, montados ao mesmo tempo.
|
||||
|
||||
Por exemplo, se você tiver uma página que escuta a tecla Enter, e um modal que escuta a tecla Enter, com um componente Select dentro desse modal que escuta a tecla Enter, você pode ter um conflito quando todos estão montados ao mesmo tempo.
|
||||
Por exemplo, se você tem uma página que escuta a tecla Enter, e um modal que escuta a tecla Enter, com um componente Select dentro desse modal que escuta a tecla Enter, você pode ter um conflito quando todos são montados ao mesmo tempo.
|
||||
|
||||
## The `useScopedHotkeys` hook
|
||||
## O hook `useScopedHotkeys`
|
||||
|
||||
Para lidar com esse problema, temos um gancho personalizado que permite ouvir teclas de atalho sem nenhum conflito.
|
||||
Para lidar com esse problema, temos um hook personalizado que permite ouvir as teclas de atalho sem qualquer conflito.
|
||||
|
||||
Você o coloca em um componente, e ele só escutará as teclas de atalho quando o componente estiver montado E quando o **escopo de atalho** especificado estiver ativo.
|
||||
Você o coloca em um componente, e ele ouvirá as teclas de atalho somente quando o componente estiver montado E quando o **escopo da tecla de atalho** especificado estiver ativo.
|
||||
|
||||
## Como ouvir teclas de atalho na prática?
|
||||
|
||||
Há duas etapas envolvidas na configuração da escuta de teclas de atalho:
|
||||
Há dois passos envolvidos na configuração da escuta de teclas de atalho :
|
||||
|
||||
1. Defina o [escopo de atalho](#what-is-a-hotkey-scope-) que escutará as teclas de atalho
|
||||
2. Use the `useScopedHotkeys` hook to listen to hotkeys
|
||||
1. Defina o [escopo da tecla de atalho](#what-is-a-hotkey-scope-) que ouvirá as teclas de atalho
|
||||
2. Use o hook `useScopedHotkeys` para ouvir as teclas de atalho
|
||||
|
||||
Configurar escopos de atalhos é necessário mesmo em páginas simples, porque outros elementos da interface do usuário, como o menu da esquerda ou o menu de comandos, também podem escutar teclas de atalho.
|
||||
Configurar escopos de teclas de atalho é necessário mesmo em páginas simples, porque outros elementos de UI como o menu à esquerda ou o menu de comando também podem ouvir teclas de atalho.
|
||||
|
||||
## Casos de uso para teclas de atalho
|
||||
|
||||
Geralmente, você terá dois casos de uso que requerem teclas de atalho:
|
||||
Em geral, você terá dois casos de uso que requerem teclas de atalho :
|
||||
|
||||
1. Em uma página ou um componente montado em uma página
|
||||
2. Em um componente do tipo modal que obtém o foco devido a uma ação do usuário
|
||||
2. Em um componente do tipo modal que assume o foco devido a uma ação do usuário
|
||||
|
||||
O segundo caso de uso pode ocorrer de forma recursiva: um dropdown em um modal, por exemplo.
|
||||
O segundo caso de uso pode ocorrer de forma recursiva : um dropdown em um modal, por exemplo.
|
||||
|
||||
### Escutando teclas de atalho em uma página
|
||||
### Ouvindo teclas de atalho em uma página
|
||||
|
||||
Exemplo :
|
||||
|
||||
@@ -76,9 +76,9 @@ const PageListeningEnter = () => {
|
||||
};
|
||||
```
|
||||
|
||||
### Escutando teclas de atalho em um componente do tipo modal
|
||||
### Ouvindo teclas de atalho em um componente do tipo modal
|
||||
|
||||
Para este exemplo, usaremos um componente modal que escuta a tecla Escape para avisar seu pai para fechá-lo.
|
||||
Neste exemplo, usaremos um componente modal que ouve a tecla Escape para informar ao pai que feche.
|
||||
|
||||
Aqui, a interação do usuário está mudando o escopo.
|
||||
|
||||
@@ -113,7 +113,7 @@ const ExamplePageWithModal = () => {
|
||||
};
|
||||
```
|
||||
|
||||
Então, no componente modal:
|
||||
Então no componente modal :
|
||||
|
||||
```tsx
|
||||
const MyDropdownComponent = ({ onClose }: { onClose: () => void }) => {
|
||||
@@ -132,19 +132,19 @@ const MyDropdownComponent = ({ onClose }: { onClose: () => void }) => {
|
||||
};
|
||||
```
|
||||
|
||||
É importante usar este padrão quando você não tem certeza se apenas usar um useEffect com montagem/desmontagem será suficiente para evitar conflitos.
|
||||
É importante usar esse padrão quando você não está seguro de que apenas usar um useEffect com mount/unmount será suficiente para evitar conflitos.
|
||||
|
||||
Esses conflitos podem ser difíceis de depurar, e pode acontecer com mais frequência do que o esperado com useEffects.
|
||||
|
||||
## O que é um escopo de atalho?
|
||||
## O que é um escopo de tecla de atalho?
|
||||
|
||||
Um escopo de atalho é uma string que representa um contexto no qual as teclas de atalho estão ativas. É geralmente codificado como um enum.
|
||||
Um escopo de tecla de atalho é uma string que representa um contexto no qual as teclas de atalho estão ativas. Geralmente é codificado como um enum.
|
||||
|
||||
Quando você muda o escopo de atalho, as teclas de atalho que estão ouvindo esse escopo serão habilitadas e as que estão ouvindo outros escopos serão desabilitadas.
|
||||
Quando você altera o escopo da tecla de atalho, as teclas associadas a esse escopo serão ativadas e as teclas associadas a outros escopos serão desativadas.
|
||||
|
||||
Você pode definir apenas um escopo por vez.
|
||||
|
||||
Como exemplo, os escopos de atalho para cada página são definidos no enum `PageHotkeyScope`:
|
||||
Como exemplo, os escopos de tecla de atalho para cada página são definidos no enum `PageHotkeyScope`:
|
||||
|
||||
```tsx
|
||||
export enum PageHotkeyScope {
|
||||
@@ -165,7 +165,7 @@ export enum PageHotkeyScope {
|
||||
}
|
||||
```
|
||||
|
||||
Internamente, o escopo atualmente selecionado é armazenado em um estado do Recoil que é compartilhado em toda a aplicação:
|
||||
Internamente, o escopo atualmente selecionado é armazenado em um estado Recoil que é compartilhado por toda a aplicação :
|
||||
|
||||
```tsx
|
||||
export const currentHotkeyScopeState = createState<HotkeyScope>({
|
||||
@@ -178,6 +178,6 @@ Mas esse estado Recoil nunca deve ser manipulado manualmente! Veremos como usá-
|
||||
|
||||
## Como funciona internamente?
|
||||
|
||||
Fizemos um wrapper fino em cima do [react-hotkeys-hook](https://react-hotkeys-hook.vercel.app/docs/intro) que o torna mais performático e evita re-renderizações desnecessárias.
|
||||
Criamos um wrapper leve em cima de [react-hotkeys-hook](https://react-hotkeys-hook.vercel.app/docs/intro) que o torna mais eficiente e evita renderizações desnecessárias.
|
||||
|
||||
Também criamos um estado do Recoil para gerenciar o estado do escopo de atalho e torná-lo disponível em toda a aplicação.
|
||||
Também criamos um estado Recoil para gerenciar o estado do escopo da tecla de atalho e torná-lo disponível em toda a aplicação.
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
title: Storybook
|
||||
description: Navegue pela biblioteca de componentes de interface do usuário do Twenty
|
||||
description: Navegue pela biblioteca de componentes UI do Twenty
|
||||
---
|
||||
|
||||
View our complete component library and documentation in Storybook.
|
||||
Veja toda a nossa biblioteca de componentes e documentação no Storybook.
|
||||
|
||||
[Open Storybook →](https://storybook.twenty.com)
|
||||
[Abra o Storybook →](https://storybook.twenty.com)
|
||||
|
||||
@@ -9,21 +9,21 @@ image: /images/user-guide/notes/notes_header.png
|
||||
|
||||
Este documento inclui as regras a seguir ao escrever código.
|
||||
|
||||
O objetivo aqui é ter uma base de código consistente, que seja fácil de ler e fácil de manter.
|
||||
O objetivo aqui é ter uma base de código consistente, fácil de ler e fácil de manter.
|
||||
|
||||
Para isso, é melhor ser um pouco mais detalhado do que ser muito conciso.
|
||||
|
||||
Lembre-se sempre de que as pessoas leem código com mais frequência do que escrevem, especialmente em um projeto de código aberto, onde qualquer um pode contribuir.
|
||||
Sempre tenha em mente que as pessoas leem código mais frequentemente do que o escrevem, especialmente em um projeto de código aberto, onde qualquer um pode contribuir.
|
||||
|
||||
Existem muitas regras que não estão definidas aqui, mas que são verificadas automaticamente por linters.
|
||||
Há muitas regras que não estão definidas aqui, mas que são verificadas automaticamente por linters.
|
||||
|
||||
## React
|
||||
|
||||
### Use componentes funcionais
|
||||
|
||||
Sempre use componentes funcionais TSX.
|
||||
Use sempre componentes funcionais TSX.
|
||||
|
||||
Não use `import` padrão com `const`, porque é mais difícil de ler e mais difícil de importar com autocompletar.
|
||||
Não use `import` padrão com `const`, pois é mais difícil de ler e mais difícil de importar com autocomplete.
|
||||
|
||||
```tsx
|
||||
// ❌ Bad, harder to read, harder to import with code completion
|
||||
@@ -39,11 +39,11 @@ export function MyComponent() {
|
||||
};
|
||||
```
|
||||
|
||||
### Props
|
||||
### Propriedades
|
||||
|
||||
Crie o tipo das props e chame de `(NomeDoComponente)Props` se não houver necessidade de exportá-lo.
|
||||
Crie o tipo das propriedades e chame-o de `(NomeDoComponente)Props` se não houver necessidade de exportá-lo.
|
||||
|
||||
Use destruturação de props.
|
||||
Use destructuring de props.
|
||||
|
||||
```tsx
|
||||
// ❌ Bad, no type
|
||||
@@ -57,7 +57,7 @@ type MyComponentProps = {
|
||||
export const MyComponent = ({ name }: MyComponentProps) => <div>Hello {name}</div>;
|
||||
```
|
||||
|
||||
#### Abstenha-se de usar `React.FC` ou `React.FunctionComponent` para definir tipos de props
|
||||
#### Evite usar `React.FC` ou `React.FunctionComponent` para definir tipos de props
|
||||
|
||||
```tsx
|
||||
/* ❌ - Bad, defines the component type annotations with `FC`
|
||||
@@ -86,9 +86,9 @@ const EmailField = ({ value }: EmailFieldProps) => (
|
||||
);
|
||||
```
|
||||
|
||||
#### Nenhuma propagação de prop de variável única em elementos JSX
|
||||
#### Proibição de Prop Spreading de Variável Única em Elementos JSX
|
||||
|
||||
Evite usar propagação de prop de variável única em elementos JSX, como `{...props}`. Essa prática geralmente resulta em um código menos legível e mais difícil de manter, pois não está claro quais props o componente está recebendo.
|
||||
Evite usar o espalhamento de props de variável única em elementos JSX, como `{...props}`. Essa prática muitas vezes resulta em código menos legível e mais difícil de manter, pois não está claro quais props o componente está recebendo.
|
||||
|
||||
```tsx
|
||||
/* ❌ - Bad, spreads a single variable prop into the underlying component
|
||||
@@ -107,11 +107,11 @@ const MyComponent = ({ prop1, prop2, prop3 }: MyComponentProps) => {
|
||||
};
|
||||
```
|
||||
|
||||
Racional:
|
||||
Justificativa:
|
||||
|
||||
- De relance, fica mais claro quais props o código está passando, tornando-o mais fácil de entender e manter.
|
||||
- Ajuda a evitar o acoplamento apertado entre componentes por meio de suas props.
|
||||
- As ferramentas de linting facilitam a identificação de props com erros ortográficos ou não utilizadas quando você lista explicitamente as props.
|
||||
- À primeira vista, é mais claro quais props o código passa, tornando mais fácil de entender e manter.
|
||||
- Ajuda a evitar o acoplamento forte entre componentes via suas props.
|
||||
- Ferramentas de linting tornam mais fácil identificar props mal digitadas ou não utilizadas quando você lista props explicitamente.
|
||||
|
||||
## JavaScript
|
||||
|
||||
@@ -139,7 +139,7 @@ onClick?.();
|
||||
|
||||
### Use `type` em vez de `interface`
|
||||
|
||||
Sempre use `type` em vez de `interface`, porque quase sempre se sobrepõem, e `type` é mais flexível.
|
||||
Sempre use `type` em vez de `interface`, porque elas quase sempre se sobrepõem e `type` é mais flexível.
|
||||
|
||||
```tsx
|
||||
// ❌ Bad
|
||||
@@ -155,9 +155,9 @@ type MyType = {
|
||||
|
||||
### Use literais de string em vez de enums
|
||||
|
||||
[Literals de string](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#literal-types) são a maneira ideal de lidar com valores que se assemelham a enum em TypeScript. Eles são mais fáceis de estender com Pick e Omit, e oferecem uma melhor experiência de desenvolvedor, especialmente com autocompletar.
|
||||
[Literals de string](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#literal-types) são o caminho a seguir para lidar com valores tipo enum no TypeScript. Eles são mais fáceis de estender com Pick e Omit, e oferecem uma melhor experiência de desenvolvedor, especialmente com autocomplete.
|
||||
|
||||
Você pode ver por que TypeScript recomenda evitar enums [aqui](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#enums).
|
||||
Você pode ver porque o TypeScript recomenda evitar enums [aqui](https://www.typescriptlang.org/docs/handbook/2/everyday-types.html#enums).
|
||||
|
||||
```tsx
|
||||
// ❌ Bad, utilizes an enum
|
||||
@@ -178,9 +178,9 @@ let color: "red" | "green" | "blue" = "red";
|
||||
|
||||
#### GraphQL e bibliotecas internas
|
||||
|
||||
Você deve usar enums que o codegen GraphQL gera.
|
||||
Você deve usar enums que o GraphQL codegen gera.
|
||||
|
||||
Também é melhor usar um enum ao usar uma biblioteca interna, para que a biblioteca interna não precise expor um tipo de literal de string que não está relacionado à API interna.
|
||||
É melhor usar um enum ao usar uma biblioteca interna, para que a biblioteca interna não precise expor um tipo literal de string que não está relacionado à API interna.
|
||||
|
||||
Exemplo:
|
||||
|
||||
@@ -231,15 +231,15 @@ const StyledTitle = styled.div`
|
||||
|
||||
### Tematização
|
||||
|
||||
Utilizar o tema para a maioria das estilizações de componentes é a abordagem preferida.
|
||||
Utilizar o tema para a maioria da estilização dos componentes é a abordagem preferida.
|
||||
|
||||
#### Unidades de medida
|
||||
|
||||
Evite usar valores `px` ou `rem` diretamente dentro dos componentes estilizados. Os valores necessários geralmente já estão definidos no tema, por isso é recomendável usar o tema para esses fins.
|
||||
Evite usar valores `px` ou `rem` diretamente dentro dos componentes estilizados. Os valores necessários geralmente já estão definidos no tema, por isso é recomendável fazer uso do tema para esses fins.
|
||||
|
||||
#### Cores
|
||||
|
||||
Abstenha-se de introduzir novas cores; em vez disso, use a paleta existente do tema. Caso haja uma situação onde a paleta não se alinhe, por favor, deixe um comentário para que a equipe possa corrigi-la.
|
||||
Evite introduzir novas cores; em vez disso, use a paleta existente do tema. Se houver uma situação em que a paleta não se alinhe, por favor, deixe um comentário para que a equipe possa corrigi-la.
|
||||
|
||||
```tsx
|
||||
// ❌ Bad, directly specifies style values without utilizing the theme
|
||||
@@ -263,9 +263,9 @@ const StyledButton = styled.button`
|
||||
`;
|
||||
```
|
||||
|
||||
## Imposição de Importações Sem Tipo
|
||||
## Impor Importações Sem Tipo
|
||||
|
||||
Evite importações de tipo. Para garantir esse padrão, uma regra do ESLint verifica e reporta todas as importações de tipo. Isso ajuda a manter a consistência e a legibilidade no código TypeScript.
|
||||
Evite importações de tipo. Para impor esse padrão, uma regra do ESLint verifica e relata qualquer violação de importação de tipos. Isso ajuda a manter a consistência e a legibilidade no código TypeScript.
|
||||
|
||||
```tsx
|
||||
// ❌ Bad
|
||||
@@ -278,18 +278,18 @@ import type { Meta, StoryObj } from '@storybook/react';
|
||||
import { Meta, StoryObj } from '@storybook/react';
|
||||
```
|
||||
|
||||
### Por que Importações Sem Tipo
|
||||
### Por Que Não Usar Importações de Tipo
|
||||
|
||||
- **Consistência**: Ao evitar importações de tipo e usar uma abordagem única para importações de tipo e valor, a base de código permanece consistente em seu estilo de importação de módulos.
|
||||
- **Consistência**: Ao evitar importações de tipo e usar uma única abordagem para importações de tipo e valor, a base de código permanece consistente em seu estilo de importação de módulo.
|
||||
|
||||
- **Legibilidade**: Importações sem tipo melhoram a legibilidade do código, deixando claro quando você está importando valores ou tipos. Isso reduz a ambiguidade e facilita a compreensão do propósito dos símbolos importados.
|
||||
- **Legibilidade**: Importações sem tipo melhoram a legibilidade do código, tornando claro quando você está importando valores ou tipos. Isso reduz a ambiguidade e facilita a compreensão do propósito dos símbolos importados.
|
||||
|
||||
- **Manutenibilidade**: Melhora a manutenibilidade da base de código porque os desenvolvedores podem identificar e localizar importações apenas de tipo ao revisar ou modificar o código.
|
||||
- **Manutenção**: Melhora a manutenibilidade da base de código porque os desenvolvedores podem identificar e localizar importações somente de tipo ao revisar ou modificar o código.
|
||||
|
||||
### Regra do ESLint
|
||||
### Regra ESLint
|
||||
|
||||
An ESLint rule, `@typescript-eslint/consistent-type-imports`, enforces the no-type import standard. Esta regra gerará erros ou avisos para quaisquer violações de importação de tipo.
|
||||
Uma regra do ESLint, `@typescript-eslint/consistent-type-imports`, aplica o padrão de importação sem tipo. Esta regra gerará erros ou avisos para qualquer violação de importação de tipo.
|
||||
|
||||
Observe que esta regra aborda especificamente casos raros em que ocorrem importações de tipo não intencionais. O próprio TypeScript desencoraja essa prática, conforme mencionado nas [notas de lançamento do TypeScript 3.8](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html). Na maioria das situações, você não deve precisar usar importações apenas de tipo.
|
||||
Observe que esta regra trata especificamente de casos isolados onde importações de tipos não intencionais ocorrem. O próprio TypeScript desencoraja essa prática, conforme mencionado nas [notas de lançamento do TypeScript 3.8](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html). Na maioria das situações, não é necessário usar importações somente de tipo.
|
||||
|
||||
Para garantir que seu código esteja em conformidade com essa regra, certifique-se de executar o ESLint como parte do seu fluxo de trabalho de desenvolvimento.
|
||||
|
||||
Reference in New Issue
Block a user