Archivos de configuración

Con los archivos de configuración, puede personalizar muchos aspectos del funcionamiento de su aplicación PWA Kit, incluidos: Acceso a API, formato de URL, administración de múltiples sitios, proxy de solicitud y renderización del lado del servidor.

Usted puede elegir en qué lenguaje se escribe el archivo de configuración: JavaScript, YAML o JSON. Se admiten las siguientes extensiones de archivo: .js, .yml, .yaml y .json.

Cuando se crea un proyecto de PWA Kit con la plantilla de la Retail React App, viene con un único archivo de configuración: app/config/default.js. Los objetos de configuración que exporta se configuran en función de las opciones brindadas al pwa-kit-create-app, pero puede actualizar su configuración en cualquier momento. A menudo es necesario realizar actualizaciones después de la generación del proyecto inicial para mantenerse sincronizado con los cambios en las instancias de B2C Commerce.

Para admitir el renderizado isomórfico, los valores de configuración se serializan a la página. ¡No deje secretos en su configuración!

Puede reemplazar default.js o complementarlo con archivos de configuración adicionales porque PWA Kit admite Configuraciones específicas del entorno, que se abarcan más adelante en esta guía.

Empecemos por analizar los objetos y las propiedades de configuración específicos disponibles en default.js o en cualquier archivo de configuración.

La cadena del proyecto que asocia su aplicación con Managed Runtime no forma parte de un archivo de configuración, pero puede encontrarse en la propiedad name en la parte superior del archivo package.json en la raíz del directorio de su proyecto. Después de la generación del proyecto inicial, puede cambiar el valor de name para que coincida con la identificación del proyecto que ve en Runtime Admin.

Antes de la versión 1.5.0 de PWA Kit, estas configuraciones se encontraban en app/api.config.js.

Para configurar el acceso a la API de B2C Commerce y Open Commerce API (OCAPI), puede editar el objeto app.commerceAPI que se exporta del archivo de configuración.

Este es un fragmento de código anotado con valores de ejemplo:

Para configurar el acceso a la API de Einstein, puede editar el objeto app.einsteinAPI.

Este es otro fragmento de código anotado con valores de ejemplo:

Para obtener más información sobre la clase CommerceAPI que consume el objeto de configuración en el fragmento de código anterior, consulte nuestra guía de arquitectura para La Retail React App.

Para obtener más información sobre las tareas de configuración de Account Manager y Business Manager para permitir acceso a la API para una instancia de B2C Commerce, consulte nuestra guía para Configurar acceso a la API.

Puede personalizar cómo se asigna formato a las URL del storefront en el objeto app.url.

El objeto app.url está configurado con los siguientes valores predeterminados:

Con esta configuración predeterminada, tanto el sitio local como la configuración local se muestran en la ruta de la URL.

Puede elegir cómo se muestra (o no se muestra) la configuración local actual en la URL estableciendo url.locale con alguno de los siguientes valores:

path: La configuración local se incluye en la ruta de la URL. Ejemplo: /en-US/women/dress
query_param: La configuración local se incluye como un parámetro de consulta. Ejemplo: /women/dress?locale=en-US
none: La configuración local no se incluye en la URL. Ejemplo: /women/dress

url.showDefaults: Este valor booleano determina si se muestran en la URL los valores del sitio o de la configuración local predeterminada. Valor predeterminado: falso.

Extraemos los sitios configurados para su aplicación en su propio archivo llamado config/sites.js. Este archivo se importa en cada archivo de configuración y se exporta dentro del objeto app. Separar los archivos de esta manera le permite sincronizar con mayor facilidad los sitios admitidos por su aplicación y los sitios definidos en su backend de Business Manager. (Puede definir sus sitios directamente en el archivo de configuración si lo prefiere).

El objeto app también contiene otras configuraciones para administrar múltiples sitios y sus alias. Estas configuraciones se tratan en más detalle en nuestra guía sobre Múltiples sitios.

El proxy de solicitud se configura en la matriz ssrParameters.proxyConfigs, que se trata en detalle en nuestra guía sobre Solicitudes de conexión del proxy.

Antes de la versión 1.5.0 de PWA Kit, estas configuraciones se encontraban en package.json.

La siguiente tabla destaca las opciones de configuración relacionadas con una renderización del lado del servidor. Estas opciones no son parte del objeto app y se expresan como propiedades individuales del objeto exports principal.

Propiedad	Descripción
`ssrParameters.ssrFunctionNodeVersion`	Cadena que determina la versión del Nodo que debe usarse para ejecutar el servidor de aplicaciones. Valores permitidos: `16.x`.
`ssrEnabled`	Booleano que activa o desactiva la construcción de los archivos necesarios para la renderización del lado del servidor. Preestablecer este valor como `falso` es una medida desaprobada desde agosto de 2021.
`ssrOnly`	Conjunto de expresiones globales en las que `` es un comodín que se corresponde con cero instancias de los caracteres o más. Determina qué archivos están disponibles exclusivamente para el sistema de renderización del lado del servidor y cuáles no están disponibles a través de la ruta de acceso `/mobify/bundle/`. Valores predeterminados para un proyecto generado recientemente: `['ssr.js', 'ssr.js.map', 'node_modules//.*']`
`ssrShared`	Conjunto de expresiones globales donde `` es un comodín que se corresponde con cero instancias de los caracteres o más. Determina qué archivos están* disponibles para el sistema de renderización del lado del servidor y a través de la ruta de acceso `/mobify/bundle/`. Valores predeterminados para un proyecto generado recientemente:

Puede incluir varios archivos de configuración en el directorio app/config/, incluidos archivos de configuración para entornos específicos.

Las configuraciones específicas del entorno pueden hacer que sus implementaciones sean más eficaces y flexibles. Por ejemplo, puede hacer lo siguiente:

Implemente un único paquete para varios entornos de Managed Runtime y haga que cada uno de los entornos se conecte a una instancia diferente de B2C Commerce.
Conecte a su propia sandbox bajo demanda durante el desarrollo local, pero conecte a instancias diferentes cuando se implemente en Managed Runtime.

Para crear un archivo de configuración específico del entorno, siga las mismas convenciones usadas en default.js, pero use el nombre del entorno objetivo como el nombre base del archivo. Use cualquiera de los formatos de archivo admitidos y la extensión de archivo correspondiente. Ejemplos: production.js, staging.json.

Una aplicación PWA Kit elige el archivo de configuración correcto que se cargará buscando en app/config y haciendo las siguientes preguntas, en el siguiente orden:

¿Hay algún archivo que coincida con el nombre del entorno que se está ejecutando actualmente en Managed Runtime?
Si se está ejecutando localmente, ¿hay un archivo llamado local con una extensión de archivo admitida?
Si aún no se encontró ningún archivo de configuración, ¿hay un archivo llamado default con una extensión de archivo admitida?

No bien la respuesta a una de estas preguntas es "Sí", PWA Kit deja de buscar y carga el archivo en cuestión.

Si dos archivos tienen el mismo nombre base, pero diferentes extensiones de archivo, la extensión de archivo con la precedencia asignada más alta es la elegida. Se asigna precedencia a las extensiones de archivo admitidas en el siguiente orden, de precedencia más alta a precedencia más baja: .js, .yml, .yaml o .json. Esto significa que entre default.js y default.json, PWA Kit cargaría default.js porque tiene la precedencia más alta.