Descripción general y sugerencias de la versión 10.0

Descripción general

En la versión 10.0, se introdujeron múltiples modificaciones (consulte las notas de la versión para obtener todos los detalles). En muchos casos, las modificaciones se realizaron para mejorar el enfoque y los principios de Jutro Design System y las bibliotecas de interfaz de usuario. En esta página, se describen los principales cambios, se explican los motivos principales y se proporcionan algunas pautas sobre qué se debe hacer para llegar a esta versión.

Note: Todavía no se han adaptado todos los componentes. En próximas versiones, los cambios descritos en este documento también se aplicarán a otros componentes.

Esto es lo que se puede prever:

Algunos componentes también se están reelaborando y se introducirán nuevas versiones en los próximos lanzamientos: los componentes fecha, junto con los componentes InputMaskField, Slider Stepper y SwitchField.
Se están revisando otros componentes y se modificarán sus API, principalmente a través de la depreciación de algunas de las propiedades existentes: Link, Breadcrumb, barras de progreso, entre otros. No se esperan cambios importantes y los componentes seguirán funcionando como lo hacen hoy.

Es posible que se introduzcan otros cambios en función de la evolución requerida de la biblioteca de Design System.

Principios de Design System

Hemos definido un conjunto de principios para las bibliotecas:

Alineación de UX

Todos los componentes de la interfaz de usuario cumplirán con las especificaciones UX de Design System. Se proporcionan opciones de personalización adicionales para una mayor flexibilidad.

Cambios sin interrupciones

Se acabaron los cambios importantes programados y frecuentes en nuestra API de componentes. Cuando cambien las bibliotecas subyacentes, trabajaremos por adelantado con nuestros usuarios para garantizar una transición sin problemas.

Responsabilidad

Solo construimos abstracciones de Jutro para aquellos aspectos que no se resuelven con los marcos de frontend. Evitamos ocultar la complejidad genérica del desarrollo del frontend, pero proporcionamos un conjunto predeterminado y seleccionado de configuraciones.

Simplicidad

Evite acoplamientos ajustados. Proporcionamos funcionalidades desacopladas, primitivas y atómicas que se pueden componer juntas. Los desarrolladores tienen el control. Nada es mágico.

Los componentes y las bibliotecas de la interfaz de usuario se han modificado para lograr estos principios y garantizar que puedan mantenerse en el futuro.

Descripción general de los cambios

Si nos centramos en los componentes de la interfaz de usuario, encontrará diferentes tipos de cambios:

Componentes eliminados u obsoletos
Nuevos componentes creados
Componentes existentes modificados: API simplificadas, funciones actualizadas y más

1. Componentes retirados por completo

Esto solo afecta a los componentes que no estaban en uso y que, según el primer principio, no se correspondían con un caso de uso de UX específico.

2. Componentes obsoletos y paquete heredado

Los componentes pueden quedar obsoletos por diferentes motivos: no responden a un caso de UX, pero aún se utilizan en algunos proyectos, nuevas alternativas disponibles, etc.

Como caso excepcional, durante esta versión, ha quedado obsoleto al mismo tiempo que se ha traslado a un nuevo paquete llamado legacy.

Note: ¿Qué tiene que hacer?

Todos estos componentes funcionarán exactamente igual que antes de quedar obsoletos y puede seguir usándolos con solo modificar la importación para obtenerlos desde el paquete legacy.

¿Desea obtener más información sobre los elementos obsoletos? Consulte la página sobre elementos obsoletos.

¿Quiere saber más sobre el paquete legacy? Consulte la legacypágina del paquete.

3. Nuevos componentes creados

Para algunos de los componentes obsoletos, se proporcionan nuevas alternativas: Accordion, Button, TextInput, CurrencyInput, PhoneNumberInput, Checkbox, RadioGroup, NumberInput, Select y más.

4. API simplificada

Al comparar los componentes nuevo TextInput y heredado InputField, notará la diferencia de la API, que pasó de más de 30 propiedades a 15, y lo mismo se aplica a la mayoría de los otros componentes reemplazados.

Descubrirá que solo se mantienen las propiedades relevantes y, si bien la coherencia es una opción deseable, no es obligatoria (p. ej., mientras que la mayoría de los componentes de entrada tienen una propiedad value, el nuevo componente Checkbox expone una propiedad checked en su lugar).

5. Tipos de propiedades

Ahora los componentes tienen tipos más específicos para sus propiedades de valor, en lugar de aceptar cualquier cosa o múltiples opciones. Ejemplo: la propiedad NumberInput value es de tipo number.

6. Eventos

En lugar de crear nuevos eventos personalizados, se utilizan los nativos y se los adapta a la necesidad de cada componente. A modo de ejemplo, en lugar de tener un evento onValueChange, se utiliza el evento nativo onChange.

Los eventos nativos se pueden invalidar. A modo de ejemplo, onChange incluso recibirá varios parámetros en función del componente:

CurrencyInput pasa el objeto de evento nativo y también el nuevo valor modificado
PhoneNumberInput pasa el objeto de evento nativo, el nuevo valor modificado y un tercer parámetro con algunos resultados de validación

7. Validación

La validación automática no está disponible en los nuevos componentes implementados. El desarrollador es responsable de manejar el proceso de validación por completo, ya que decide qué, cuándo y cómo se realiza la validación. Sin embargo, los componentes proporcionan 2 mecanismos para permitir la validación del desarrollador:

stateMessages: esta propiedad del componente define cuáles son los mensajes de error que se mostrarán en el componente. Los desarrolladores solo tienen que pasar los mensajes y el componente los mostrará.
Algunos parámetros auxiliares: componentes específicos (p. ej., PhoneNumberInput) proporcionan un objeto con el resultado de algunas validaciones predefinidas como tercer parámetro del evento onChange. El desarrollador podría utilizar esta información para validar la entrada del usuario.

8. Tokens de tematización y diseño

Las variables CSS ya no forman parte de la API de un componente, sino que son un detalle de implementación interna.

Obtenga más información sobre nuestra API de componentes.

Para los componentes existentes, las variables CSS no se están modificando y siguen funcionando como antes de esta versión.

Se proporciona un nuevo mecanismo de tematización: tokens de diseño. Esto no afecta la forma en que la aplicación interactúa con la tematización, pero cambia la forma en que se define el tema y la API del componente, ya que ahora forman parte de él.

9. Escotillas de escape

Los componentes ahora se corresponden con las especificaciones UX y esto reduce, en algunos casos, la flexibilidad que proporcionan los componentes para lograr comportamientos o aspectos más allá de las especificaciones. Con el fin de proporcionar algunas alternativas, se introducen escotillas de escape.

Según el componente, se proporcionan diferentes opciones, pero estas son las más comunes:

Tokens de diseño: se trata del mecanismo de personalización del tema.
Propiedades HTML nativas: en muchos componentes se puede pasar cualquier propiedad HTML nativa y esta se pasará al elemento de nivel superior o a un elemento específico dentro del componente. Consulte la documentación de cada componente para obtener más detalles.
Propiedades dangerouslySet: permiten la invalidación completa de parte de un componente.
className: este atributo está presente en todos los componentes y permite establecer el atributo clase en el elemento superior del componente.
ref con controladores imperativos: ref está disponible en muchos componentes, pero sin proporcionar el acceso completo al elemento. En lugar de características específicas restringidas por la biblioteca.

10. Desacoplamiento

La biblioteca de componentes se centra en los aspectos de presentación de los componentes. La responsabilidad del componente es manejar su aspecto de presentación, por eso, otras responsabilidades se eliminan o al menos se “degradan” a funciones de ayuda o secundarias.

Estos son algunos ejemplos:

API de eventos: legacy Button incluía un desencadenante automático de eventos para la API de eventos cuando se detectaba el clic. Esto no se incluye en el nuevo componente Button.
Dependencia @jutro/auth: ahora es una dependencia de pares. El objetivo es que ningún componente incluya el acoplamiento directo con el paquete @jutro/auth. Sin embargo, hoy en día, esta dependencia existe en algunos componentes como Avatar.
Dependencia @jutro/router: existe una dependencia entre @jutro/components y el paquete @jutro/router. Algunos componentes, como Link se movieron al paquete @jutro/router.
Backend y enlace al modelo de datos: las propiedades de los componentes y sus tipos no se corresponden con el modelo de datos, sino que se definen en función de la responsabilidad del componente.

Cambios específicos

1. Estado de los componentes

Componente existente	Cambio realizado	Alternativa	Comentarios
`Accordion`	Obsoleto y trasladado a `legacy`	`Accordion`
`AdaptativeDataView`	Obsoleto y trasladado a `legacy`	Patrón de UX
`Address`	Obsoleto y trasladado a `legacy`	Patrón de UX
`AnimationGroup`	Retirado por completo	Ninguno, solo uso interno
`ApplicationHeader`	Obsoleto y trasladado a `legacy`	Patrón de UX	Otros subcomponentes `header` permanecen estables, pero solo para utilizarlos en el contexto del patrón de UX
`AsyncButton`	Obsoleto y trasladado a `legacy`	`Button`
`BreakpointTracker`	Obsoleto y trasladado a `legacy`	Ninguno, solo uso interno
`Button`	Obsoleto y trasladado a `legacy`	`Button`
`ButtonLink`	Obsoleto y trasladado a `legacy`	`Button`
`CheckboxField`	Obsoleto y trasladado a `legacy`	`Checkbox`
`CheckboxGroupField`	Obsoleto y trasladado a `legacy`	`CheckboxGroup`
`Collapse`	Obsoleto y trasladado a `legacy`	Ninguno, solo uso interno
`ColorSwatch`	Retirado por completo	Ninguno
`Container`	Obsoleto y trasladado a `legacy`	Ninguno, solo uso interno
`Chevron`	Obsoleto y trasladado a `legacy`	`Icon`
`CurrencyField`	Obsoleto y trasladado a `legacy`	`CurrencyInput`
`DataTable`	Obsoleto y trasladado a `legacy`	Patrón de UX
`DataView`	Obsoleto y trasladado a `legacy`	Patrón de UX
`DropdownSelectField`	Obsoleto y trasladado a `legacy`	`Select`, `MultipleSelect`
`FieldSkeleton`	Retirado por completo	`TextArea`
`FileUploadField`	Obsoleto y trasladado a `legacy`	Patrón de UX
`Footer`	Obsoleto y trasladado a `legacy`	Uso a través de `Floorplan`
`FooterCopyRight`	Obsoleto y trasladado a `legacy`	Uso a través de `Floorplan`
`FooterNavBar`	Obsoleto y trasladado a `legacy`	Uso a través de `Floorplan`
`FooterNavLink`	Obsoleto y trasladado a `legacy`	Uso a través de `Floorplan`
`FooterText`	Obsoleto y trasladado a `legacy`	Uso a través de `Floorplan`
`FormSkeleton`	Retirado por completo	`TextArea`
`Header`	Obsoleto y trasladado a `legacy`	Patrón de UX	Otros subcomponentes `header` también obsoletos: `HeaderActions`, `LogoTitle`, `HelpHeading`, `HelpLink`, `HelpParagraph`, `HelpPopover` y `HelpElement`
`GlobalizationSettingsCard`	Obsoleto y trasladado a `legacy`	Ninguno
`IconButton`	Obsoleto y trasladado a `legacy`	`Button`
`ImageRadioButtonField`	Obsoleto y trasladado a `legacy`	`RadioGroup`, `Radio`	No hay reemplazo exacto
`InlineNotification`	Cambio de poca importancia: se eliminó el texto inicial predeterminado del mensaje (Acción correcta, Advertencia...)
`InputField`	Obsoleto y trasladado a `legacy`	`TextInput`
`InputNumberField`	Obsoleto y trasladado a `legacy`	`NumberInput`
`IntlPhoneNumberField`	Obsoleto y trasladado a `legacy`	`PhoneNumberInput`
`JsonForm`	Retirado por completo	Ninguno	El uso de metadatos quedó obsoleto
`Layout`	Obsoleto y trasladado a `legacy`	Otros componentes de composición y disposición
`ListView`	Obsoleto y trasladado a `legacy`	Patrón de UX
Componentes `LinkSkeleton`	Retirado por completo	Ninguno
`LiveRegion`	Retirado por completo	Ninguno, solo uso interno
`Location`	Obsoleto y trasladado a `legacy`	Patrón de UX
`Main`	Obsoleto y trasladado a `legacy`	Ninguno, solo uso interno
`MapArea`	Obsoleto y trasladado a `legacy`	Ninguno	Las características relacionadas con el mapa no están dentro del ámbito de aplicación
`MapTooltipContent`	Obsoleto y trasladado a `legacy`	Ninguno
`MenuSkeleton`	Retirado por completo	`TextArea`
`PageHead`	Retirado por completo	Ninguno
`PageLayout`	Retirado por completo	Otros componentes de composición y disposición
`PageLoader`	Obsoleto y trasladado a `legacy`	`Loader`
`PanelLayout`	Retirado por completo	Otros componentes de composición y disposición
`PhoneNumberField`	Obsoleto y trasladado a `legacy`	`PhoneNumberInput`
`PrivateRoute`	Retirado por completo	Ninguno, solo uso interno
`QuickView`	Obsoleto y trasladado a `legacy`	Patrón de UX
`RadioButtonCardField`	Obsoleto y trasladado a `legacy`	`RadioGroup`, `Radio`	No hay reemplazo exacto
`RadioButtonField`	Obsoleto y trasladado a `legacy`	`RadioGroup`, `Radio`
`RadioField`	Obsoleto y trasladado a `legacy`	`RadioGroup`, `Radio`
`RadioGroup`	Obsoleto y trasladado a `legacy`	`RadioGroup`, `Radio`
`ResponsiveElement`	Retirado por completo	Ninguno, solo uso interno
`RouteTracker`	Retirado por completo	Ninguno, solo uso interno
`ScrollToError`	Obsoleto y trasladado a `legacy`	Ninguno, solo uso interno
`SettingsCard`	Obsoleto y trasladado a `legacy`	Ninguno
`SkipNav`	Retirado por completo	Ninguno, solo uso interno
`StickyFooter`	Obsoleto y trasladado a `legacy`	Uso a través de `Floorplan`
`TabbedContainer`	Retirado por completo	`TabGroup`
`Table`	Obsoleto y trasladado a `legacy`	Patrón de UX
`TableAdapters`	Obsoleto y trasladado a `legacy`	Patrón de UX	Incluye `ActionColumnAdapter`, `ActionItemAdapter`, `DisplayColumnAdapter`, `FieldColumnAdapter` y `RadioColumnAdapter`
`TableSkeleton`	Retirado por completo	`TextArea`
`TableView`	Obsoleto y trasladado a `legacy`	Patrón de UX
`TextAreaField`	Obsoleto y trasladado a `legacy`	`TextArea`
`TextHighlight`	Retirado por completo	Ninguno, solo uso interno
`ThemeSettingsCard`	Obsoleto y trasladado a `legacy`	Ninguno
`ToastProvider` / `ToastField`	Cambio de poca importancia: se eliminó el texto inicial predeterminado del mensaje (Acción correcta, Advertencia...)
`TreeView`	Se pasó de la versión preliminar de laboratorio a estable
`TypeaheadMultiSelectField`	Obsoleto y trasladado a `legacy`	`Combobox`, `MultipleCombobox`

Note: Otros subcomponentes también se han visto afectados por los cambios, pero no se enumeran aquí para mayor claridad.

Note: Algunos componentes también se están reelaborando y se introducirán nuevas versiones en los próximos lanzamientos: los componentes fecha, además de los componentes InputMaskField, Slider Stepper y SwitchField.

Se están revisando también otros componentes y se modificarán sus API, principalmente a través de la depreciación de algunas de las propiedades existentes.

2. Cambios de tipo

Tipo de valor

El tipo value, o propiedades equivalentes, se ha modificado para que coincidiera con el caso de uso del componente:

Componente	Propiedad	Tipo anterior	Tipo nuevo
`Checkbox`	`checked`	`any`	`bool`
`Combobox`	`value`	`any`	`string`
`CurrencyInput`	`value`	`any` - `{ amount: number, currency: string }`	`{ amount: number, currency: ISOCurrencyCodes }`
`NumberInput`	`value`	`any`	`number`
`PhoneNumberInput`	`value`	`any` - `{ countryCode: {code: string }, phoneNumber: string }`	`{ phoneNumber: string, countryCode: ISOCountryCodes }`
`TextArea`	`value`	`any`	`string`
`TextInput`	`value`	`any`	`string`
`RadioGroup`	`value`	`any`	`string`
`Select`	`value`	`any`	`string`

Las opciones de componentes listas desplegables se cambiaron de availableValues a children de tipo SelectOption o ComboboxOption.

La definición ha cambiado de:

<DropdownSelectField
  availableValues={[
    {
      code: string,
      name: string,
    },
    {
      code: string,
      name: string,
    },
  ]}
/>

<Combobox>
  <ComboboxOption
    value={{
      id: string,
      label: string,
    }}
  />
  <ComboboxOption
    value={{
      id: string,
      label: string,
    }}
  />
</Combobox>

3. “Mapeo” de propiedades

Se definen algunas propiedades nuevas, que reemplazan total o parcialmente las anteriores.

`readOnly` antiguo en comparación con `displayOnly` y `readOnly` nuevos

En los componentes legacy, la propiedad readOnly hacía que el componente se mostrara como texto, sin la apariencia de una entrada. Sin embargo, los nuevos componentes tienen dos estados diferentes:

readOnly: entrada que puede recibir el foco, pero no es editable
displayOnly: texto simple sin el aspecto y estilo de entrada

Obtenga más información sobre estos estados aquí

Mensajes de componentes

Los mensajes de error y el estado de error en los componentes legacy se definían pasando la propiedad validationMessages en combinación con la propiedad showErrors. Si esta propiedad se estableciera en true, el error se vería en el estado error y se mostrarían los mensajes.

Los nuevos componentes proporcionan la propiedad stateMessages y, cuando se proporcionan, ya muestran cualquier mensaje dado y establecen el estado de error en el campo.

validationMessages: ['message 1', 'message 2'];
showErrors: true;

stateMessages: {
  error: ['message 1', 'message 2'];
}

mín./máx. en comparación con minValue/maxValue

Las propiedades personalizadas para definir el valor mínimo o máximo aceptado han sido reemplazadas por las propiedades nativas min y max.

Propiedad `tooltip`

Esta propiedad sigue estando disponible, pero se ha simplificado a tooltip: { text: string | IntlShapeObject; trigger?: string }; en lugar de varias propiedades y opciones de representación personalizadas.

`required` es solo visual

Se eliminó cualquier lógica de validación para la opción required. Ahora required establecido en true solo determina que debe aparecer un '*' junto al rótulo.

Propiedades `defaultValue` y `initialValue`

Las propiedades defaultValue y initialValue no son equivalentes.

La propiedad defaultValue se eliminó y ahora los componentes no proporcionan un valor específico que se asigne cuando el usuario no proporciona ningún valor.

La propiedad initialValue se utiliza para componentes no controlados, por eso, se asigna un valor inicial a la entrada.

Propiedades HTML nativas

Los componentes de entrada, pero también otros, permiten al desarrollador pasar no solo las propiedades definidas por la API, sino también otras propiedades HTML relacionadas con ese tipo de componente. A modo de ejemplo, TextInput o NumberInput ambos aceptarían las propiedades que aceptaría un elemento HTML input.

Estas propiedades pueden restringirse en función de la API y el comportamiento del componente:

Algunas propiedades nativas son invalidadas por la API del componente: min y max en NumberInput.
Otras propiedades están predefinidas y no se pueden modificar: type no tiene ningún efecto en NumberInput.

Encontrará más detalles aquí

Propiedades eliminadas

No se han incluido varias propiedades comunes en los nuevos componentes. Además, son candidatas para quedar obsoletas en los componentes restantes.

Según la propiedad, el motivo detrás de su eliminación u obsolescencia puede ser diferente:

Práctica no recomendada (id)
Acoplamiento del modelo de datos y el componente UX (path)
Comportamiento adaptativo (propiedades phone o phoneWide)
Funciones no obligatorias (autotrim)

Esta es una lista de las propiedades más comunes eliminadas. Algunas se mencionan en secciones anteriores, ya que son reemplazadas por otras:

autotrim
dataType
defaultValue
id
nullable
onValueChange
path
phone
phoneWide
secondaryLabelId
showOptional
tablet
Propiedades relacionadas con la validación: enableMultipleValidation, onValidationChange, showErrors, registerValidation, validationMessages y validator
visible
*******ClassName (todas las propiedades className que no sean className para el elemento superior)

4. Evento `onChange`

La firma del evento onChange es:

onChange(event: React.ChangeEvent, value: valueType, options?: any)

event: Este primer parámetro es el objeto de evento asociado con el evento desencadenado. En algunos casos, es el objeto de evento nativo y, en otros, un objeto personalizado que lo replica pero está adaptado a las necesidades o la implementación del componente. Este objeto proporciona acceso a algunos de los detalles de implementación del componente subyacente.

Note: Debe usarse con precaución. Dado que los detalles de implementación están expuestos y no forman parte de la API del componente, algunos cambios podrían afectar el código que depende de ellos.

La mayoría de las funciones necesarias se proporcionan a través de otros mecanismos: parámetros adicionales, propiedad de referencia, etc., pero esto se proporciona para permitir cualquier caso extremo que pueda faltar.

value: Este es el valor actual del componente. Es del mismo tipo que las propiedades value y initialValue del componente y se puede depender de él para cualquier validación o gestión de estado.
options: No es utilizado por todos los componentes, pero cuando se utiliza, proporciona acceso a otra información complementaria. Inicialmente, esto se utiliza para compartir resultados relacionados con la validación que podrían estar integrados en el componente. Un ejemplo es el componente PhoneNumberInput, en el que este parámetro proporciona acceso a un objeto {errorCode: number} con el código correspondiente a un error de validación específico.

5. Error de coincidencia de datos

Si bien los tipos de datos de los componentes legacy se alinearon con el modelo de datos, los nuevos componentes no lo están y solo admiten un formato de entrada/salida. Por esta razón, al interactuar con el SDK, deberá transformar los datos que entran y salen de él.

Estos son algunos ejemplos:

CurrencyInput leerá/escribirá { currency: ISOCurrencyCodes (string), amount: number }, pero el SDK requiere { currency: string, amount: string }
Select leerá/escribirá el {id: string, label: string} del elemento seleccionado, pero el SDK requiere { code: string, name?: string}
NumberInput leerá/escribirá number, pero el SDK requiere string
PhoneNumberInput leerá/escribirá { phoneNumber: string, countryCode: ISOCountryCodes (string) }, pero el SDK requiere { number: string, countryCode: string }

6. Validación

La validación es responsabilidad del desarrollador. Los nuevos componentes ya no realizan ninguna validación (ver a continuación).

Los componentes la admiten de la siguiente manera:

Tienen una propiedad statusMessages que permite a los desarrolladores pasar todos los mensajes de error que se mostrarán. Apenas se proporcionen, los mensajes se mostrarán y el componente utilizará la apariencia de “estado de error” (por ejemplo, un color rojo alrededor de un cuadro de entrada).
Proporciona algunas características complementarias: los componentes como PhoneNumberField tienen un mecanismo de validación incorporado y su resultado se proporciona como el tercer parámetro del evento onChange.

Depende del desarrollador decidir lo siguiente:

Qué tipo de validación se requiere y su implementación.
Cuándo se deben mostrar los mensajes de error y dónde (p. ej., en lugar de mostrar el error al nivel del componente, se pueden utilizar errores al nivel de la página).
Si se debe utilizar la lógica proporcionada del componente.

Esto incluye cualquier mensaje o validación del tipo “campo obligatorio”.

7. Tokens de diseño y microfrontends (MFE)

Dado que el mecanismo de tematización desde la perspectiva de la aplicación no ha cambiado, solo la forma en que se administra la tematización (ahora a través de tokens de diseño), no es necesario hacer nada diferente para que la tematización funcione con MFE.

Hay casos que debe tener en cuenta: la tematización basada en shell en las antiguas variables de GW y microfrontend con tokens de diseño puede hacer que los componentes no reciban nuevos valores o que no funcionen como se prevé. Es posible que tenga algunos problemas con la definición del estilo. Plantee cualquier problema que encuentre y le proporcionaremos una guía más detallada sobre cómo utilizar variables antiguas de GW y tokens de diseño en los microfrontends en las siguientes versiones.

8. Nuevo .themesConfig

Antes, teníamos archivos de configuración separados para cada tema, que los usuarios tenían que colocar en src/config/... y, luego, asignar a themeConfig en la función de inicio.

Actualmente, hemos combinado todo en un solo archivo .themesConfig.json, donde puede tener varias definiciones de los diferentes temas.

{
  "sampleTheme": {
    "name": "sampleTheme",
    "baseTheme": "Consumer"
    "styleOverrides": "styles/sampleTheme/styleOverrides.css",
    "variableOverrides": "styles/sampleTheme/variableOverrides.css"
  },
  "nexusTheme": {
    "name": "nexusTheme",
    "tokens": {
      "input-path": "src/tokens/Nexus/*.json",
      "output-file-name": "nexusTheme.css"
    }
  },
}

Cuando lleva a cabo una actualización desde una versión anterior a la 10.0.x en la que se ejecuta un codemod, la configuración del tema de formato antiguo que estaba en src/config/.. migra a la nueva configuración del tema de formato.

Warning: Si tenía varias definiciones de tema en archivos separados, solo la que se usa actualmente en la configuración del tema de la aplicación se agregará al nuevo .themesConfig.json.

9. Orden de prioridad de las opciones de tematización

En el pasado, algunos componentes utilizaban variables --GW- para la personalización de la tematización. Con la incorporación del mecanismo de tokens de diseño, se agrega un nuevo conjunto de variables (--JDS-) y se asignan algunos mapeos adicionales y valores predeterminados. Sin embargo, la compatibilidad con versiones anteriores se mantiene en los componentes existentes.

¿Cómo se comportará la tematización según como se defina la tematización en estos casos?

Situación de ejemplo: ha establecido una invalidación de variable --GW- en el lado del cliente para el componente Link:--GW-LINK-COLOR

Caso 1: no está usando tokens. No hay ninguna configuración para tokens en el archivo .themesConfig.json.

El componente Link utiliza la invalidación de variable --GW- del cliente

Caso 2: ha comenzado a utilizar tokens, uno de ellos corresponde al color aplicado al componente Link (--JDS-LINK-COLOR). La información del token se agrega a .themesConfig.json y la salida incluye una invalidación del color Link.

El componente Link utiliza el valor del token de diseño, asignado a las variables CSS --JDS-LINK-COLOR durante el proceso de transformación

Caso 3: ha comenzado a utilizar tokens de diseño, pero no hay ningún token para el color del componente Link.

El componente Link utiliza la invalidación de variable --GW- del cliente

En cualquiera de los casos anteriores, si utiliza la propiedad className del componente Link para definir un estilo diferente, este tendrá prioridad sobre las variables CSS.

10. Tematización de componentes antiguos y nuevos

Para JDP 10, se incluyeron nuevas versiones de algunos componentes, que reemplazaron a los existentes: Accordion, Button y la mayoría de los componentes relacionados con entradas. Al mismo tiempo, hay algunos componentes relacionados con las entradas que aún no se han reemplazado: InputMaskField, ToggleField, SwitchField, StepperField, Slider y los componentes fecha.

Entre los cambios introducidos con los componentes recién implementados, uno de los más relevantes es la tematización: estos componentes están completamente preparados para trabajar con los tokens de diseño y han definido un conjunto completamente nuevo de variables CSS. Sin embargo, estas opciones de tematización no se corresponden por completo con las opciones de personalización proporcionadas por sus predecesores.

Con base en lo anterior, puede haber situaciones en las que ambos grupos de componentes coexistan, porque forman parte de la misma aplicación o porque esto está sucediendo debido a la incrustación de MFE.

Estos son algunos ejemplos:

Entradas no actualizadas y nuevas entradas utilizadas: por ejemplo, una página que utiliza los componentes InputMaskField y TextInput.
Una versión nueva y heredada del mismo componente utilizado en una aplicación: por ejemplo, una aplicación que usa legacy/components/Accordion y components/Accordion.
Aplicación shell que usa componentes antiguos (heredados y no actualizados) con un MFE incrustado que usa los componentes nuevos.

También es posible que coexistan 2 mecanismos de tematización: que dependen de variables CSS y usen tokens de diseño.

Warning: Las variables CSS no forman parte de la API del componente y se consideran un detalle de implementación interna. Para los componentes del paquete legacy, las variables CSS aún se consideran un método válido y no están sujetas a cambios.

Hemos realizado una comparación de la apariencia de los componentes y las diferentes combinaciones para que se vean “similares”.

Note: Quizás no sea posible configurar exactamente un componente antiguo como uno nuevo, o viceversa.

Cómo hacer que las entradas antiguas y nuevas se parezcan con variables CSS

Si desea utilizar componentes no reelaborados como ToggleField, SwitchField o DateFields junto con componentes nuevos sin usar tokens de diseño, debe agregar su mapeo a variablesOverrides.css para unificar la apariencia de los componentes: https://stash.guidewire.com/projects/JUT/repos/jutro-main/browse/packages/jutro-theme-styles/src/gwToTokens/gwToTokens.js

(Nota: Este mapeo se puede ampliar en el futuro).

Cómo hacer que los componentes nuevos se parezcan a los antiguos con los tokens de diseño

Los componentes en la versión JDP 10 se pueden ajustar al mismo estilo que los componentes legacy utilizando los tokens de diseño disponibles. Puede haber algunas diferencias, pero la apariencia en general será similar.

A continuación, se describen algunos aspectos que deben tenerse en cuenta y diferencias:

Familias tipográficas:

Con los tokens y el archivo gwToTokens proporcionado, no habrá diferencias visuales en las familias de fuentes (el valor predeterminado es "Source Sans 3").
Si no se usan tokens, la familia tipográfica será diferente (similar pero diferente): legacy usa "Source Sans Variable", "Helvetica", "Arial", sans-serif;", mientras que el valor predeterminado es "Source Sans 3", "Helvetica", "Arial", sans-serif.

Accordion: El color de fondo del encabezado y el contenido de la tarjeta no se establecieron para el componente heredado Accordion. El Accordion actual proporciona tokens para ambos:

background-color: var(--JDS-ACCORDION-CARD-CONTENT-COLOR-BACKGROUND); // #fff

background-color: var(--JDS-ACCORDION-CARD-HEADER-COLOR-BACKGROUND); // #fff

Button: la definición del espaciado entre borde y texto es diferente:

Heredado Button: padding: 0 var(--GW-SPACING-6); // 0 20px
Espaciado actual entre borde y texto: var(--JDS-BUTTON-PRIMARY-PADDING); // 0 16px

Componentes relacionados con las entradas: hay algunas diferencias.

El estilo de altura de línea de rótulos es diferente. Cuando en labelPosition: left la alineación vertical del rótulo es diferente, el espacio entre el rótulo y el control es diferente.
- Heredado: line-height: var(--GW-LINE-HEIGHT-LABEL); // calculates to 21px
- Actuales: line-height: var(--JDS-FONT-LABEL-MEDIUM-LINE-HEIGHT); // calculates to 18px
El estilo de altura de línea del rótulo secundario es diferente:
- Heredado: var(--GW-LINE-HEIGHT-SECONDARY-LABEL); // calculates to 18px
- Actuales: line-height: var(--JDS-FONT-LABEL-SMALL-LINE-HEIGHT); // calculates to 15px
Tooltip: La descripción emergente es más grande para los componentes antiguos. Si labelPosition: left, la descripción emergente se renderiza en un lugar diferente.
Asterisco obligatorio: se ve más pequeño para los componentes actuales, debido a los diferentes valores de espesor de la fuente.
Opacidad Disabled: Este valor para el rótulo y el rótulo secundario solo se establece para los campos nuevos.
Mensajes de error: El formato de los mensajes de estado de error es diferente, por ejemplo, los componentes heredados tienen color rojo para el texto.