Mejores prácticas de LWC para flujos de pantalla ☁️

Screen Flows, parte de Salesforce Flow , permite a los desarrolladores y administradores crear interfaces de usuario y vincularlas a los datos de Salesforce mediante herramientas de código o sin código. Los flujos de pantalla permiten a los desarrolladores usar componentes web Lightning (LWC) como elementos de flujo . Sin embargo, la creación de LWC para un flujo requiere que siga algunas prácticas recomendadas. Al hacerlo, aumenta el rendimiento de sus LWC y su componente funciona mejor dentro del motor de tiempo de ejecución de Flow.

En este blog, primero nos sumergimos en cómo funciona la administración de estado en el tiempo de ejecución de Flow y luego compartimos algunas prácticas recomendadas de administración de estado y eventos que debe seguir al crear LWC para sus flujos de pantalla.

Mejores prácticas para la gestión del estado de LWC en flujos de pantalla

El tiempo de ejecución de Flow se adhiere a los principios de diseño de gestión de estado de LWC. Funciona mejor cuando los componentes de LWC que representa no modifican sus propios atributos @api y, en su lugar, solicitan que se realice un cambio FlowAttributeChangeEvents .

Este patrón es esencial por dos razones.

1. Los componentes que permiten a sus padres controlar sus parámetros @api se reutilizan más fácilmente porque permiten que la aplicación controle el estado en lugar de la propia lógica empresarial interna del componente.
2. Al activar eventos de cambio de atributo, el tiempo de ejecución de Flow puede mantener una imagen precisa del estado del componente, lo que le permite controlar las interacciones entre componentes, como la visibilidad de campo condicional.

El uso de las reglas de linter de Salesforce LWC es una excelente manera de asegurarse de que su componente no modifique los parámetros @api . Configure un linter que use las reglas de linter de LWC en su entorno de desarrollo, asegurándose específicamente de que se aplique la configuración lwc/no-api-reasignments .

A continuación se muestra un ejemplo de un componente de entrada de texto simple. Demuestra cómo debe activarse un FlowAttributeChangeEvent en lugar de actualizar el parámetro @api de LWC.

Código problemático

Código compatible

Mejores prácticas para eventos LWC en flujos de pantalla

En las próximas secciones, profundizaremos en las mejores prácticas para eventos de flujo como FlowAttributeChangeEvent y FlowNavigationEvent .

Mejores prácticas de evento de cambio de atributo

Esta sección presenta una lista de FlowAttributeChangeEvent (ver documentos ) Qué hacer y qué no hacer .

1. No modifique los atributos @api en el componente. En su lugar, active el evento FlowAttributeChangeEvents .
2. Active el evento en los controladores de eventos o en los métodos invocados dentro de los controladores de eventos.
3. Limite el parámetro de valor del evento a los siguientes tipos de datos:
   1. Cadena
   2. Número
   3. booleano
   4. JSON (para tipos de registros)
4. Asegúrese de que el tipo de datos del parámetro de valor FlowAttributeChangeEvent coincida con el tipo de datos del parámetro @api de LWC.
5. Reaccione a los cambios en @api utilizando un patrón get/set cuando corresponda. Esto también es necesario para la comunicación cruzada entre los componentes cuando se utilizan componentes de pantalla reactiva (Beta) .

El siguiente ejemplo demuestra el uso de get/set para contar las actualizaciones de un parámetro @api en lugar de simplemente incrementar un contador antes de activar un evento de cambio de atributo. Vale la pena señalar que los dos patrones a continuación son válidos pero logran resultados ligeramente diferentes.

En el escenario anterior, this.changeCounter se incrementará siempre que el usuario ingrese un cambio en la entrada de texto y siempre que el tiempo de ejecución de Flow determine que la propiedad textValue ha cambiado. Esto tendrá en cuenta la inicialización de componentes y las interacciones entre componentes cuando se utilizan componentes de pantalla reactivos .

Nota: será necesario usar una variable intermedia para generar actualizaciones desde el método set. En este ejemplo, presentamos textValueToRender para este propósito.

Veamos un ejemplo de código en el que incrementamos un contador antes de activar un evento de cambio de atributo. En este escenario, no usamos el patrón get/set .

En este caso, this.changeCounter se incrementará cada vez que el usuario ingrese un cambio en la entrada de texto.

6. Utilice parámetros @track para mantener un estado de componente local modificable.

El siguiente ejemplo muestra un selector de color que presenta al usuario un cuadro de texto de entrada y algunas muestras. Tenga en cuenta que el componente selector de color devuelve el color al flujo, por lo que solo color debe ser un parámetro @api , los miembros selectedSwatchId e inputValue son solo internos y, por lo tanto, no necesitan ningún decorador.

colorPicker.js

swatch.color === newColor); this.selectedSwatchId = foundSwatch && foundSwatch.id;
} get color() { return this.inputValue;
} handleSwatchSelected(event) { // Select get the swatch data for the clicked swatch: const selectedSwatch = this.ALL_SWATCHES.find(swatch => swatch.id === event.target.dataset.id); const changeEvent = new FlowAttributeChangeEvent(‘color’, selectedSwatch.color); this.dispatchEvent(changeEvent); } handleInputValueChange(event) { this.inputValue = event.target.value; const changeEvent = new FlowAttributeChangeEvent(‘color’, this.inputValue); this.dispatchEvent(changeEvent);
} «>

7. Utilice un método get para combinar @api para construir una variable derivada para la vista.

Saludo.js

8. Aplique la misma lógica en el método set de @api que contribuye a una variable miembro derivada. Esto es necesario para la gestión del estado de los componentes internos en escenarios complejos. Esto garantizará que un cambio realizado en cualquier atributo contribuyente hará que el valor se represente correctamente, independientemente del orden en que se establezcan los atributos.

desplegable.js

{ return option.isSelected && option.value === selectedValue; }); if (!isAlreadySelected) { const attributeChange = new FlowAttributeChangeEvent(‘value’, selectedValue); this.dispatchEvent(attributeChange); }
} computeOptions() { if (this.internalOptionLabels.length !== this.internalOptionValues.length) { return []; } return this.internalOptionLabels.map((label, index) ==> { const value = this.internalOptionValues[index]; const isSelected = this.internalValue === value; return { label, value, isSelected }; });
} «>

9. No modifique los parámetros de FlowAttributeChangeEvent después de la construcción. De forma predeterminada, las instancias de FlowAttributeChangeEvent están compuestas y burbujeadas .

10. Evite activar los eventos FlowAttributeChangeEvents y FlowNavigationXxx al mismo tiempo. La razón de esto es que puede conducir a condiciones de carrera. Nunca hay una garantía de que el componente LWC haya tenido tiempo de representar los valores actualizados en el momento en que comenzamos el proceso de navegación.

Mejores prácticas de eventos de cambio de navegación

Además del FlowAttributeChangeEvent , los LWC personalizados pueden activar eventos de navegación para moverse entre pantallas y pausar o finalizar flujos.

La intención de los eventos de navegación es permitir que los autores de LWC personalizados incluyan mecanismos de control adicionales dentro de sus componentes. Con ese fin, los eventos de navegación deben activarse al reaccionar a la interacción del usuario final.

Consulte la lista de lo que se debe y lo que no se debe hacer a continuación cuando planee usar eventos de navegación.

1. Ejecute eventos de navegación en controladores de eventos (o en el método que invocan).
2. No active eventos de navegación fuera de los controladores de eventos, ya que genera una mala experiencia para el usuario final.
3. No active eventos de navegación en controladores de ciclo de vida como renderedCallback y connectedCallback .

La lógica para omitir pantallas debe descansar en los nodos de decisión de flujo y no debe determinarse durante el ciclo de vida de una pantalla. Además, la navegación en una pantalla ficticia puede provocar un rendimiento deficiente del flujo.

Conclusión

Nos encanta cuando los desarrolladores crean soluciones innovadoras con componentes web Lightning combinados con flujos. Seguir las mejores prácticas descritas en este blog garantiza que sus componentes se integren bien en el motor de tiempo de ejecución de Flow y funcionen como se espera.

Referencias

Sobre los autores

Josh Goodman es miembro principal del personal técnico con más de 7 años de experiencia como desarrollador en Salesforce. A lo largo de su mandato, Josh ha trabajado en muchas características interesantes, como agregar informes y tableros a Salesforce One móvil, llevar Wave Charting a Lightning, agregar compatibilidad con carpetas anidadas a las páginas de inicio de informes y tableros, y convertir la interfaz de usuario de Flow de Aura a LWC. . Actualmente está trabajando en nuevas y emocionantes características de tiempo de ejecución de la interfaz de usuario para Flows.

Mohith Shrivastava es promotor de desarrollo en Salesforce con una década de experiencia en la creación de productos a escala empresarial en la plataforma de Salesforce. Actualmente se está enfocando en las herramientas para desarrolladores de Salesforce, Flow, Apex y Lightning Web Components en Salesforce. Mohith se encuentra actualmente entre los principales contribuyentes en Salesforce Stack Exchange, un foro de desarrolladores donde los desarrolladores de Salesforce pueden hacer preguntas y compartir conocimientos. Puedes seguirlo a través de su Twitter @msrivastav13.