@griddo/cx 11.4.17-rc.5 → 11.4.18-rc.0

package/README.md

@@ -4,25 +4,18 @@ Griddo CX es un package dentro del monorepo de Griddo (`packages/griddo-cx`) que
 
 # Arquitectura
 
-CX está escrito como una biblioteca en TypeScript. \**Los consumidores de la misma son el *Adapter, el framework SSG y una serie de scripts en TypeScript que viven en el propio `package/griddo-cx` y que son utilizados por infra, normalmente invocados mediante un `npm run ...`
+CX está escrito como una biblioteca en TypeScript que exporta herramientas node (`import { ... } from "@griddo/cx"`) y componentes React (`import { ... } from "@griddo/cx/react"`). Los consumidores son el Adapter, el framework SSG[^1] y una serie de scripts (comandos) en TypeScript que se definen en el propio `package/griddo-cx` estos son utilizados por infra, normalmente invocados mediante un `npm run ...`
 
-\*Para los casos del Adapter y los “scripts para infra”, estos utilizarán directamente el código Typescript de la biblioteca de CX. Para el caso del SSG, este utilizará el código bundlelizado disponible en `@griddo/cx` y `griddo/cx/react`
-
-Como ejemplo aquí vemos un snippet dentro de Gatsby (actual framework SSG) importando un componente `<GriddoIntegrations>` que forma parte de la biblioteca de CX, en concreto del export de react.
-
-```tsx
-// src/components/template.tsx
-import { GriddoIntegrations } from "@griddo/cx/react";
-```
+[^1]El framework SSG, actualmente Gatsby es el único actor que consume el código de CX ya bundelizado (`import { ... } from "@griddo/cx"`), Adapter y comandos para infra consumen el código de cx en Typescript directamente.
 
 ## Exports
 
-CX tiene dos exports separados: **main y react**.
+CX tiene dos exports separados: **core y react**.
 
-- **main** se exporta en `@griddo/cx` . Es código que se ejecuta en un entorno nodejs.
-- **react** se exporta en `@griddo-cx/react` . Es código React :)
+- **core** se exporta en `@griddo/cx`. Es código que se ejecuta en un entorno nodejs.
+- **react** se exporta en `@griddo-cx/react` . Es código React.
 
-**Ejemplo de import**
+**Ejemplos de imports**
 
 ```tsx
 // React import
@@ -47,7 +40,7 @@ Este comando, `yarn run build` se ejecuta en el despliegue del monorepo, npm pre
 
 ## Archivo de configuración
 
-CX tiene un archivo de configuración en el raíz del package `griddo-cx/cx.config.js` donde se establecen ciertos valores globales para todo el package.
+CX tiene un archivo de configuración en el raíz del package `griddo-cx/config.ts` donde se establecen ciertos valores globales para todo el package.
 
 Los siguientes puntos están incluidos en el archivo de configuración y deben ser leídos de este, evitando hardcodear o volver a calcularlos en el resto del código.
 
@@ -68,13 +61,10 @@ const config = {
 };
 ```
 
-El contenido del archivo de configuración se leerá con la función `getConfig()` donde sea que necesitemos acceder a la misma.
-
-**Ejemplo**
+**El contenido del archivo de configuración se importa directamente.**
 
 ```tsx
-const config = getConfig()
-const { proDomain, ... } = config
+import { cofig } from "...";
 ```
 
 ### Dominio \*pro-\*\*
@@ -87,7 +77,7 @@ Este `pro-` se especifica directamente y una sola vez en el archivo de configura
 
 Si es necesario obtener la versión de CX la podemos tomar directamente del archivo de configuración
 
-### Sistema de paths interno
+### Sistema de paths internos de CX
 
 Mediante el archivo de configuración se establecen unas rutas absolutas globales a todo CX e instancia (ya sea instancia interna del monorepo o la de un cliente) que nos ayudará a orquestar los artefactos durante los LifeCycles de un render. Un uso parecido a los `__dirname` o `__filename` de javascript CommonJS.
 
@@ -98,7 +88,7 @@ Ya que la mayoría de las veces el uso de estas rutas son durante el render de u
 **Ejemplo**
 
 ```tsx
-const { __exports, __cache } = getConfig().paths("mi-dominio");
+const { __exports, __cache } = config.paths("mi-dominio");
 console.log(__exports); // ...export/sites/**mi-dominio**
 console.log(__cache); // ...griddo-cx/.cx-cache/**mi-dominio**
 ```
@@ -115,10 +105,9 @@ Esta son las rutas existentes.
 **Ejemplo de uso real**
 
 ```tsx
-import { getConfig } from "./utils/config";
+import { config } from "../config";
 
 // Sin dominio
-const config = await getConfig();
 const { __cx, __ssg } = config.paths();
 const storeDir = path.join(__cx, "store");
 const templateFile = path.join(__ssg, "src/components/template.tsx");
@@ -130,18 +119,14 @@ console.log(__exports); // /griddo/packages/griddo-cx/.cx-cache/**pre-griddo**
 
 ## LifeCycles
 
-Los LifeCycles se utilizan dentro del contexto de un _Adapter_. Se usa a través de la función `doLifeCycle` que ejecuta un batch de funciones (`actions`) de forma secuencial. Informando por consola del inicio, fin y tiempo invertido en ejecutar todas las funciones del `actions`, manejando cualquier error en las mismas. En caso de error, es posible indicar un número de _attempts_ que hará que se ejecute de nuevo el clico de vida las veces indicadas.
+Los LifeCycles se utilizan dentro del contexto de un _Adapter_. Se usa a través de la función `doLifeCycle` que ejecuta un batch de funciones (`actions`) de forma secuencial. Informando por consola del inicio, fin y tiempo invertido en ejecutar todas las funciones del `actions`, manejando cualquier error en las mismas. En caso de error, es posible indicar un número de _retries_ que hará que se ejecute de nuevo el clico de vida las veces indicadas.
 
-En CX existen estos LifeCycles: `Prepare`, `Restore`, `Data`, `SSG`, `Relocation`, `Meta`, `Archive`, `Clean`, `HealthCheck` y uno de `__DEBUG__` internamente son iguales (usan `doLifeCycle`) y se utilizan estos distintos nombres para identificarlos dentro de un render, poner distintos _attempts_, etc..
+En CX existen estos LifeCycles: `Prepare`, `Restore`, `Data`, `SSG`, `Relocation`, `Meta`, `Archive`, `Clean` y `HealthCheck`; internamente son iguales (usan `doLifeCycle`) y se utilizan estos distintos nombres para identificarlos dentro de un render, poner distintos _retries_, etc..
 
 **Ejemplo:**
 
 ```tsx
-await doLifeCycle({
-	name: "SSG",
-	attempts: 2, // intentará hacer **todos** las actions dos veces si hay un error en alguno de ellos
-	actions: [func1, func2, func3],
-});
+await doLifeCycle("SSG", () => syncAction(context));
 ```
 
 # Scripts para infra.
@@ -174,7 +159,6 @@ El Adapter es el responsable de manejar el proceso de render mediante las utilid
 
 <aside>
 💡 Los Adapters utilizarán el código TypeScript de CX, no el bundlelizado. Ya que el propio adapter también se bundleliza.
-
 </aside>
 
 ### **Obligaciones de un Adapter**
@@ -222,7 +206,6 @@ A su vez, en cada despliegue que exista en la instancia también se borrarán ya
 
 <aside>
 💡 Coming soon: Gestión automática de la caché de Griddo (no de los frameworks SSGS)
-
 </aside>
 
 # Logs

package/{cx.config.d.ts → build/config.d.ts}

@@ -1,5 +1,2 @@
 import type { CXConfig } from "./exporter/types/global";
-
-declare const config: CXConfig;
-
-export default config;
+export declare const config: CXConfig;