@griddo/cx 10.4.19 → 10.4.21

package/README.md

@@ -1,93 +1,28 @@
 # Griddo package
 
-## TO-DO
-
-- [ ] Crear el store utilizando un HASH como nombre de archivo y no el ID.
-- [ ] Manejar el store teniendo en cuenta el ID de las páginas leyendo el objeto y no el nombre del archivo.
-
----
 
 El package `griddo-cx` está dividido en dos carpetas principales: una para la lógica de negocio en `/exporter` y otra para Gatsby (builder) `/src`.
 
-Estas dos carpetas estarían representando dos estados o fases diferenciadas en la ejecución de un "render/build de cx" completo.
+## `/exporter`
 
-1. **Fetching**: Obtención, postprocesado y guardado de los datos en el sistema de archivos.
+**Griddo Exporter** es el script _orquestador_ que debe llamar **una vez por cada dominio** a los distintos procesos que implican la realización de la publicación de una instancia.
 
-2. **Rendering** Ejecución de Gatsby para construir los sites utilizando los datos descargados
+En el exporter se desarrolla todo lo necesario para la conexión con API, post-procesado de los datos y generación de JSONS finales de los sites con "el estándar Griddo". Aquí es donde se ejecuta la mayor parte de la lógica: obtención de páginas, listados, distribuidores, idomas, etc. Todo está implementado como una _library_, nada se ejecuta por sí solo. Lo tiene que hacer el Adapter.
 
-## 1. Fetching
+**Adapter**
 
-En la fase de Griddo se desarrolla todo lo necesario para la conexión con API, post-procesado de los datos y generación de JSONS finales de los sites con "un formato Griddo". Aquí es donde se ejecuta la mayor parte de la lógica: obtención de páginas, listados, distribuidores, idomas, etc.
+El adapter es una parte del código de CX que orquesta un render, utilizando como servicios la _library_ de CX y el framework de SSG disponible. Actualmente hay un SSG, Gatsby. Por lo tanto hay un adapter a Gatsby. Lógica de negocio y SSG ya no están mezclados.
 
 Si hay un requerimiento en CX es muy probable que sea en esta parte donde haya que trabajar.
 
-**Estructura de carpetas**
-
-```text
-| src/
-  | adapters/
-    | gatsby/ # Adapta la salida (JSON) de Griddo -> Gatsby
-  | services/
-  | types/
-  | utils/
-  | create-build-data.ts
-  | build-complete.ts
-  | index.ts
-  | reset-render.ts
-```
-
-## 2. Rendering (Gatsby)
-
-Esta fase se ejecuta inmediatamente después de la primera. Se ejecuta `yarn gatsby build` lo que generá un build utilizando todos los datos que se descargaron en la carpeta `store`.
-
-El código de Gatsby (por ahora el único SSG usado por Griddo) está en la carpeta `./src` junto con los archivos en el root: `gatsby-config.ts`, `gastsby-node.ts`, `gatsby-browser.ts` y `gatsby-ssr.ts`.
-
-```text
-| src/
-  | components/
-    | Head.tsx
-    | template.tsx
-  | htm.tsx
-  | gatsby-node-utils.ts
-  | types.ts
-  | utils.ts
-| gatsby-browser.ts
-| gatsby-config.ts
-| gatsby-node.ts
-| gatsby-ssr.ts
-```
-
-# Griddo Exporter
-
-El punto de entrada para CX está en `src/index.js` que ejecuta **Griddo Exporter**, publicado en `./build/index.js` del cual podemos encontrar el código TypeScript en `./scripts/griddo-exporter.ts`
+## `/src`
 
-**Griddo Exporter** es el script _orquestador_ que llama **una vez por cada dominio** a los distintos procesos que implican la realización del build de un dominio.
+Aquí es donde reside el SSG actual (Gatsby) junto a archivos en el raíz, como `gatsby-node`, etc. Este ssg será llamado por el Adapter dentro del `Data LifeCycle`. El SSG solo debe saber que hay una carpeta `/store/` con los .json que representan las páginas a renderizar. Desde la `cx-library` también podrá hacer uso de otras utilidades, servicios y componentes. Por ejemplo utilizará la función `getBuildPagesFromStore` para obtener las páginas anteriormente creadas desde el store. Es decir, El SSG "no sabe" dónde están las páginas, tan solo tiene una función que se las va a devolver.
 
-`BUILD-COMPLETO = PROCESOS * DOMINIOS`
 
-## Los procesos
-
-Los distintos procesos llamados desde **Griddo Exporter** son:
-
-### API Fetch
-
-**`yarn run api-fetch`**
-
-Realiza toda la consulta de datos a la API de los sites (páginas, distribuidores, etc...) de un dominio, post-procesa y construye los `pageObjets`. Estos `pageObjects` son guardados como archivos JSON en una carpeta del sistema de archivos, creando lo que llamamos un **Store**.
-
-Este Store no está acoplado con ningún sistema de renderización (Gatsby), son solo archivos JSON que describen los sites y páginas con el estándar que hemos diseñado desde Griddo.
-
-### Gatsby build
-
-**`gatsby-build`**
-
-Se leen los JSON del store y se crean las páginas pasándolos directamente (0 pre/post procesado) a la función `creatPages` de Gatsby.
-
-### Post build
+---
 
-- Se crean Robots
-- Se crean sitemaps.xml del render
-- Se crear un archivo **build_report**info.json para notificar a la API de la finalización del render
-- Se mueven el bundle generado por Gatsby de /public a /dist (esto se debería deprecar)
+## TO-DO
 
-**`post-build`**
+- [ ] Crear el store utilizando un HASH como nombre de archivo y no el ID.
+- [ ] Manejar el store teniendo en cuenta el ID de las páginas leyendo el objeto y no el nombre del archivo.

package/build/adapters/gatsby/index.d.ts

@@ -0,0 +1,2 @@
+declare function runGatsbyAdapter(): Promise<void>;
+export { runGatsbyAdapter };

package/build/adapters/gatsby/utils.d.ts

@@ -0,0 +1,27 @@
+import { Fields } from "@griddo/core";
+declare const attempts: {
+    prepare: any;
+    restore: any;
+    data: any;
+    ssg: any;
+    relocation: any;
+    meta: any;
+    archive: any;
+    clean: any;
+};
+/**
+ * Return the assetPrefix url `assetPrefix/domain`
+ */
+declare function getGatsbyAssetPrefixSlug(domain: string): string;
+/**
+ * Format Cloudinary or DAM URL
+ *
+ * @param image The image url
+ * @param width With of the image
+ * @param height Height of the image
+ * @param format Format of the image
+ * @returns A composed URL for the Cloudinary or DAM service
+ */
+declare function formatImage(image: Fields.Image | string, width: number, height: number, format?: string): string | null;
+declare function gatsbyBuild(domain: string): void;
+export { attempts, formatImage, gatsbyBuild, getGatsbyAssetPrefixSlug };

package/build/adapters/index.d.ts

@@ -0,0 +1,3 @@
+import { runGatsbyAdapter } from "./gatsby";
+export type Adapters = "gatsby";
+export { runGatsbyAdapter };

package/build/browser/index.d.ts

@@ -0,0 +1,5 @@
+import { Core } from "@griddo/core";
+declare function filterBodyIntegrationFromPosition(integrations: Array<Core.PageIntegration>, position: "start" | "end"): string[];
+declare function filterHeadIntegrations(integrations: Array<Core.PageIntegration>): string[];
+declare function filterPositionIntegrations(integrations: Array<Core.PageIntegration>, position: "head" | "start" | "end"): string[];
+export { filterBodyIntegrationFromPosition, filterHeadIntegrations, filterPositionIntegrations, };

package/build/build-complete.d.ts

@@ -0,0 +1,18 @@
+type Report = {
+    authControl: {
+        Authorization: string;
+        "Cache-Control": string;
+        lang?: string | undefined;
+    } | undefined;
+    sites: Array<{
+        siteId: number;
+        publishHashes: Array<string>;
+        siteHash: string | null;
+        unpublishHashes: Array<string>;
+    }>;
+};
+/**
+ * Informa a la API del estado de publicación de los sites: published y unpublished.
+ */
+export declare function buildComplete(report: Report): Promise<void>;
+export {};