@griddo/cx 11.4.18-rc.0 → 11.4.18-rc.1

package/README.md

@@ -4,18 +4,25 @@ Griddo CX es un package dentro del monorepo de Griddo (`packages/griddo-cx`) que
 
 # Arquitectura
 
-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 ...`
+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 ...`
 
-[^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.
+\*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";
+```
 
 ## Exports
 
-CX tiene dos exports separados: **core y react**.
+CX tiene dos exports separados: **main y 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.
+- **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 :)
 
-**Ejemplos de imports**
+**Ejemplo de import**
 
 ```tsx
 // React import
@@ -40,7 +47,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/config.ts` 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/cx.config.js` 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.
 
@@ -61,10 +68,13 @@ const config = {
 };
 ```
 
-**El contenido del archivo de configuración se importa directamente.**
+El contenido del archivo de configuración se leerá con la función `getConfig()` donde sea que necesitemos acceder a la misma.
+
+**Ejemplo**
 
 ```tsx
-import { cofig } from "...";
+const config = getConfig()
+const { proDomain, ... } = config
 ```
 
 ### Dominio \*pro-\*\*
@@ -77,7 +87,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 internos de CX
+### Sistema de paths interno
 
 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.
 
@@ -88,7 +98,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 } = config.paths("mi-dominio");
+const { __exports, __cache } = getConfig().paths("mi-dominio");
 console.log(__exports); // ...export/sites/**mi-dominio**
 console.log(__cache); // ...griddo-cx/.cx-cache/**mi-dominio**
 ```
@@ -105,9 +115,10 @@ Esta son las rutas existentes.
 **Ejemplo de uso real**
 
 ```tsx
-import { config } from "../config";
+import { getConfig } from "./utils/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");
@@ -119,14 +130,18 @@ 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 _retries_ 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 _attempts_ 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` y `HealthCheck`; internamente son iguales (usan `doLifeCycle`) y se utilizan estos distintos nombres para identificarlos dentro de un render, poner distintos _retries_, etc..
+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..
 
 **Ejemplo:**
 
 ```tsx
-await doLifeCycle("SSG", () => syncAction(context));
+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],
+});
 ```
 
 # Scripts para infra.
@@ -159,6 +174,7 @@ 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**
@@ -206,6 +222,7 @@ 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/build/adapters/gatsby/index.d.ts

@@ -0,0 +1,4 @@
+/**
+ * Render every instance domain with the Gatsby adapter.
+ */
+export declare function renderDomainsWithGatsbyAdapter(domain: string): Promise<void>;

package/build/{exporter/adapters → adapters}/gatsby/utils.d.ts

@@ -7,7 +7,7 @@
  * - If assetPrefix or domain is falsy, returns ""
  * - If the domain is not "pro-", returns ""
  */
-declare function getGatsbyAssetPrefixWithDomain(domain: string, proDomainPrefix: string): string;
+declare function getGatsbyAssetPrefixWithDomain(domain: string): string;
 /**
  * Spawn a new node process `yarn gatsby-build`
  * @note This proccess (`yarn gatsby-build`) can not access to the custom Griddo
@@ -18,10 +18,5 @@ declare function runGatsbyBuildCommand(assetPrefixWithDomain: string): void;
  * Update the Griddo's `/dist` dir with the contents from `public` dir only
  * with files of type: js, json and css.
  */
-declare function extractAssetsFromDist(domain: string, needsAssetPrefix: boolean): Promise<void>;
-declare function syncGatsbyRender({ domain, pagesToCreate, pagesToDelete, }: {
-    domain: string;
-    pagesToCreate: Array<number>;
-    pagesToDelete: Array<number>;
-}): void;
-export { extractAssetsFromDist, getGatsbyAssetPrefixWithDomain, runGatsbyBuildCommand, syncGatsbyRender, };
+declare function createDistFromGatsbyPublic(domain: string, needsAssetPrefix: boolean): Promise<void>;
+export { createDistFromGatsbyPublic, getGatsbyAssetPrefixWithDomain, runGatsbyBuildCommand, };

package/build/commands/prepare-domains-render.d.ts

@@ -0,0 +1 @@
+export {};