@oondemand/create-central-oon 0.3.11 → 0.3.14

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,195 @@
1
+ # ADVANCED_UX_PATTERNS.md — UX Avançada Declarativa no OonCore
2
+
3
+ Este documento orienta Codex e outras IAs a usarem o máximo de recursos do OonCore antes de criar telas customizadas. O foco é transformar padrões recorrentes de sistemas operacionais em **manifesto declarativo** e componentes reutilizáveis.
4
+
5
+ ## Objetivo
6
+
7
+ Permitir que uma Central declare experiências avançadas como:
8
+
9
+ ```txt
10
+ Entidade principal
11
+ ├── grid principal com filtros e ações
12
+ └── modal de detalhe com abas
13
+ ├── resumo
14
+ ├── dados principais
15
+ ├── itens relacionados editáveis inline
16
+ └── registros relacionados somente leitura
17
+ ```
18
+
19
+ Caso de referência: `OrcamentoProjeto -> OrcamentoItem -> Pagamento`.
20
+
21
+ ## Regra de ouro para IAs
22
+
23
+ Antes de criar uma página React customizada, verifique se a necessidade pode ser resolvida por:
24
+
25
+ 1. `collections[]` no `central.ui.json`.
26
+ 2. `list.filters` e `list.rowActions`.
27
+ 3. `detailModal.tabs`.
28
+ 4. `form.groups`.
29
+ 5. `relatedGrid`.
30
+ 6. `rowActions` declarativas.
31
+ 7. Um pequeno `customComponent` isolado.
32
+
33
+ Código customizado de página inteira deve ser a última opção.
34
+
35
+ ## Padrão 1 — Tela principal limpa
36
+
37
+ A tela principal de uma coleção operacional deve conter apenas:
38
+
39
+ - título e descrição;
40
+ - filtros;
41
+ - busca;
42
+ - botão novo;
43
+ - grid principal;
44
+ - ações por linha.
45
+
46
+ Ela **não deve** expandir detalhes complexos abaixo do grid. Relações, edição profunda e acompanhamento devem ir para a modal de detalhe.
47
+
48
+ ## Padrão 2 — Modal de detalhe com abas
49
+
50
+ Use uma modal quando o usuário precisar operar um registro com várias perspectivas.
51
+
52
+ Abas recomendadas:
53
+
54
+ - `summary`: visão rápida de indicadores e contadores.
55
+ - `form`: dados principais do registro.
56
+ - `relatedGrid`: filhos editáveis, como itens do orçamento.
57
+ - `readonlyGrid`: registros relacionados apenas para consulta, como pagamentos gerados.
58
+
59
+ ## Padrão 3 — Formulários agrupados
60
+
61
+ Formulários longos devem ser divididos em grupos semânticos:
62
+
63
+ ```json
64
+ {
65
+ "type": "form",
66
+ "groups": [
67
+ { "label": "Identificação", "fields": ["codigo", "nome", "status"] },
68
+ { "label": "Faturamento", "fields": ["cliente", "cnpj", "contato"] },
69
+ { "label": "Observações", "fields": ["observacoes"] }
70
+ ]
71
+ }
72
+ ```
73
+
74
+ ## Padrão 4 — Itens relacionados editáveis inline
75
+
76
+ Quando uma entidade principal tem muitos itens filhos, como itens de orçamento, serviços, parcelas, documentos ou pedidos, prefira `relatedGrid` com `editMode: "inline"`.
77
+
78
+ Comportamento esperado:
79
+
80
+ - edição célula a célula;
81
+ - indicação de linha alterada;
82
+ - botão `Salvar` por linha;
83
+ - botão `Cancelar` por linha;
84
+ - validação antes de salvar;
85
+ - loading por linha;
86
+ - erro por linha;
87
+ - atualização automática dos dados relacionados.
88
+
89
+ ## Padrão 5 — Ações por linha
90
+
91
+ Ações de domínio devem ser declaradas no manifesto e executadas por HTTP.
92
+
93
+ Exemplo:
94
+
95
+ ```json
96
+ {
97
+ "id": "gerarPagamento",
98
+ "label": "Gerar pagamento",
99
+ "type": "apiAction",
100
+ "method": "POST",
101
+ "endpoint": "/api/ss-eventos/orcamentos-itens/:id/gerar-pagamento",
102
+ "disabledWhen": { "field": "pagamentoId", "exists": true },
103
+ "refresh": ["self", "pagamentos", "resumo"]
104
+ }
105
+ ```
106
+
107
+ A regra de negócio continua na Central ou no backend. O Core apenas renderiza, valida permissões, executa a ação e atualiza a interface.
108
+
109
+ ## Padrão 6 — Relações declarativas
110
+
111
+ Sempre que possível, declare relações no manifesto:
112
+
113
+ ```json
114
+ {
115
+ "relations": {
116
+ "itens": {
117
+ "model": "OrcamentoItem",
118
+ "foreignKey": "projetoId",
119
+ "parentKey": "_id"
120
+ },
121
+ "pagamentos": {
122
+ "model": "Pagamento",
123
+ "foreignKey": "projetoId",
124
+ "parentKey": "_id"
125
+ }
126
+ }
127
+ }
128
+ ```
129
+
130
+ Assim, qualquer aba pode referenciar `relation: "itens"` sem repetir configuração.
131
+
132
+ ## Padrão 7 — Abas somente leitura
133
+
134
+ Use `readonlyGrid` para dados relacionados que não devem ser editados naquela tela.
135
+
136
+ Exemplo: pagamentos gerados a partir dos itens de um orçamento.
137
+
138
+ ## Padrão 8 — Refresh entre abas
139
+
140
+ Ações em uma aba podem afetar outras abas. O manifesto deve declarar o refresh esperado:
141
+
142
+ ```json
143
+ "refresh": ["self", "pagamentos", "resumo"]
144
+ ```
145
+
146
+ Significado:
147
+
148
+ - `self`: recarrega o grid atual;
149
+ - `pagamentos`: recarrega a aba pagamentos;
150
+ - `resumo`: recalcula cards da aba resumo;
151
+ - `parent`: recarrega o registro principal.
152
+
153
+ ## Quando ainda usar componente customizado
154
+
155
+ Use componente customizado apenas quando:
156
+
157
+ - houver visualização muito específica de negócio;
158
+ - o padrão ainda não existir no Core;
159
+ - a regra envolver interação visual não generalizável;
160
+ - o componente puder ser isolado e reaproveitado.
161
+
162
+ Mesmo nesses casos, prefira plugar o componente em uma aba `customComponent` da modal, e não substituir a página inteira.
163
+
164
+ ## Checklist para Codex
165
+
166
+ Antes de criar tela customizada:
167
+
168
+ - [ ] A coleção principal pode usar `collections[]`?
169
+ - [ ] Os filtros cabem em `list.filters`?
170
+ - [ ] As ações de linha cabem em `list.rowActions`?
171
+ - [ ] O detalhe cabe em `detailModal`?
172
+ - [ ] Os campos cabem em `form.groups`?
173
+ - [ ] Os filhos cabem em `relatedGrid`?
174
+ - [ ] As ações dos filhos cabem em `rowActions`?
175
+ - [ ] A consulta relacionada cabe em `readonlyGrid`?
176
+ - [ ] O refresh entre abas está declarado?
177
+ - [ ] RBAC está no backend e refletido no manifesto?
178
+
179
+ ## Antipadrões
180
+
181
+ Evite:
182
+
183
+ - recriar shell, menu, roteamento e providers;
184
+ - codificar página inteira só para mudar layout do formulário;
185
+ - chamar `fetch` direto se `useOonApi`/client do Core atende;
186
+ - duplicar regra de permissão apenas no frontend;
187
+ - hardcode de endpoints quando a metadata pode resolver;
188
+ - editar `.ooncore/` manualmente;
189
+ - criar variações visuais fora do padrão sem necessidade.
190
+
191
+ ## Implementação disponível no Core
192
+
193
+ Use `collections[].list` para filtros, colunas e ações da lista principal. Use `collections[].relations` para nomear relações reutilizáveis e `collections[].detailModal.tabs` para declarar abas `summary`, `form`, `relatedGrid`, `readonlyGrid` ou `customComponent`.
194
+
195
+ Ações por linha (`rowActions`) podem abrir a modal (`openDetailModal`), navegar (`navigate`) ou chamar endpoints (`apiAction`). Condições declarativas (`exists`, `equals`, `notEquals`, `in`, `gt`, `gte`, `lt`, `lte`) controlam visibilidade e bloqueio sem hardcode de Central no Core.
package/docs/CODEX.md CHANGED
@@ -11,6 +11,37 @@ A fonte de verdade desta documentação é a versão instalada do pacote `@oonde
11
11
  3. Leia `.ooncore/context.generated.md`.
12
12
  4. Identifique o recurso do Core que resolve a necessidade antes de criar código customizado.
13
13
 
14
+ ## Leitura obrigatória por tipo de tarefa
15
+
16
+ ### Backend/domínio
17
+
18
+ - `BACKEND_PATTERNS.md`
19
+ - `COLLECTIONS_AND_PIPELINES.md`
20
+ - `CONNECTORS_AND_INTEGRATIONS.md`
21
+ - `RBAC_SECURITY.md`
22
+
23
+ ### Frontend/manifesto
24
+
25
+ - `FRONTEND_PATTERNS.md`
26
+ - `FRONTEND_MANIFEST_REFERENCE.md`
27
+
28
+ ### UX avançada, modais, abas e itens relacionados
29
+
30
+ Leia antes de criar páginas customizadas:
31
+
32
+ - `ADVANCED_UX_PATTERNS.md`
33
+ - `DETAIL_MODAL_AND_RELATED_GRIDS.md`
34
+
35
+ Use estes documentos quando a necessidade envolver:
36
+
37
+ - modal com abas;
38
+ - dados principais agrupados;
39
+ - grids relacionados;
40
+ - edição inline;
41
+ - ações por linha;
42
+ - registros filhos como itens, parcelas, produtos, documentos ou pagamentos;
43
+ - telas onde o usuário opera um registro principal e seus relacionamentos.
44
+
14
45
  ## Princípios obrigatórios
15
46
 
16
47
  - Escreva apenas o domínio da Central.
@@ -23,6 +54,7 @@ A fonte de verdade desta documentação é a versão instalada do pacote `@oonde
23
54
  - Não exponha chaves em código, templates ou documentação gerada.
24
55
  - Não altere arquivos gerados do Core se houver extensão declarativa disponível.
25
56
  - Prefira models, validations, triggers, hooks, mappings, documents, pipelines, integrations e overrides declarativos.
57
+ - Antes de criar uma página React customizada, tente resolver com `central.ui.json`, `detailModal`, `form.groups`, `relatedGrid`, `readonlyGrid` e `rowActions`.
26
58
 
27
59
  ## Ordem de decisão
28
60
 
@@ -31,8 +63,9 @@ Ao implementar uma necessidade, siga esta ordem:
31
63
  1. Configuração existente do Core.
32
64
  2. Declaração em `central.config.js` ou `central.ui.json`.
33
65
  3. Model, validation, trigger, hook ou mapping no backend da Central.
34
- 4. Override local pequeno e isolado.
35
- 5. Código customizado somente quando o Core não oferecer extensão adequada.
66
+ 4. Modal, abas, grid relacionado, ação e renderer declarativos do Core.
67
+ 5. Override local pequeno e isolado.
68
+ 6. Código customizado somente quando o Core não oferecer extensão adequada.
36
69
 
37
70
  ## Entrega segura
38
71