Lightning Web Components

Q: ¿Mis componentes sobrevivirán a las actualizaciones del paquete?

Si los construiste contra la superficie estable (objetos refin__ vía LDS/UI API, las clases Apex globales, la composición a nivel de página), sí, por el contrato del paquete administrado. Lo que se rompe es depender de los internos de los componentes empaquetados o de clases públicas, que es justo de lo que este artículo te sigue alejando.

Desarrollador 5 min de lectura Actualizado en julio de 2026

Construir interfaces personalizadas alrededor de REDA Financials es trabajo de LWC ordinario: los objetos son objetos personalizados, los servicios de datos son los estándares, y tus componentes conviven con los del paquete en cualquier página de Lightning. El oficio está en aquello contra lo que construyes.

Acceso a datos desde tus componentes

Primero Lightning Data Service: lightning-record-form, los adaptadores wire y la UI API hablan con fluidez los objetos refin__: CRUD con diseños, FLS y validaciones resueltos sin esfuerzo.
Tu Apex donde vive la lógica: un controlador que consulta facturas, o que llama a refin.GlobalTaxService para una vista previa de impuestos en vivo dentro de tu propia interfaz de cotización (consulta Desarrollo con Apex).
Los cambios de estado desde la UI equivalen a contabilizar: un botón en tu componente que aplica un PATCH del estado a "Posted" mediante LDS ejecuta el motor completo; construye tu manejo de errores alrededor del mensaje de DML, que ya es texto listo para el usuario.

Componer con las páginas del paquete

Las páginas de registro están abiertas: coloca tus componentes en las páginas de registro empaquetadas (o clona el flexipage y reorganízalo): un panel personalizado de "contexto de arrendamiento" junto a la factura, una tarjeta de propiedad en el activo.
Los formularios se extienden sin código: antes de escribir un componente para "agregar un campo al formulario de la factura", revisa los conjuntos de campos: los formularios empaquetados agregan columnas de forma declarativa.
La navegación es estándar: tus componentes enlazan directamente a cualquier registro o listado de REDA mediante el servicio de navegación de la plataforma; las pantallas empaquetadas hacen lo mismo en sentido inverso.

Trata los componentes empaquetados como páginas, no como piezas. Los LWC del paquete (formularios, espacios de trabajo, el Centro Financiero) son superficies de producto: colócalos, no los programes. La superficie programática estable es el modelo de datos + la API global de Apex; tu UI innova alrededor de eso, y las actualizaciones nunca te rompen.

Patrones que valen la pena

Paneles de contexto verticales: los datos de tu industria (propiedad, proyecto, caso) mostrados junto al documento financiero que los referencia.
Creación guiada: un asistente que recopila los datos de tu dominio, luego crea el documento en borrador mediante LDS y entrega al usuario el formulario estándar para la parte contable.
Dashboards de solo lectura: consultas con adaptadores wire sobre facturas o el mayor, con la visualización que elijas, complementando los dashboards estándar.

Un componente resuelto: la vista previa de impuestos de cotización de arrendamiento de Meridian

El equipo de arrendamiento de Meridian Properties Group quería mostrar el alquiler con impuestos incluidos durante la negociación, antes de que existiera ninguna factura. El componente es un LWC de REDA de manual: tu UI, tu controlador, el motor del paquete. El controlador arma una solicitud para refin.GlobalTaxService a partir de los datos de la cotización:

refin.GlobalTaxService.TaxRequest req = new refin.GlobalTaxService.TaxRequest();
req.entityId        = quote.entityId;
req.accountId       = quote.tenantAccountId;
req.transactionDate = Date.today();
req.side            = 'Sales';

refin.GlobalTaxService.TaxLineRequest line = new refin.GlobalTaxService.TaxLineRequest();
line.lineKey   = 'rent-1';          // echoed back for correlation
line.amount    = quote.monthlyRent;
line.productId = quote.rentProductId;
req.lines      = new List<refin.GlobalTaxService.TaxLineRequest>{ line };

refin.GlobalTaxService.TaxResponse res = refin.GlobalTaxService.calculateTax(req);

La respuesta trae totalTaxAmount y resultados por línea (tasa, monto, cuentas contables resueltas), correlacionados de vuelta mediante lineKey. Como el contrato no realiza ningún DML y nunca lanza una excepción al llamador, el componente verifica res.success, muestra res.errorMessage cuando es falso, y copia los valores que necesita en su propia forma de respuesta para el wire. Cuando se firma el arrendamiento y la factura real se contabiliza meses después, los números coinciden al centavo: un solo motor, dos consumidores.

Las barandas de seguridad que hereda tu UI

Comportamiento de la plataforma/paquete	Consecuencia de diseño para tu componente
Los documentos contabilizados quedan bloqueados salvo por campos de flujo de trabajo en lista blanca	Desactiva las opciones de edición cuando el estado es Posted; de todos modos el guardado fallaría, con el mensaje del paquete
Contabilizar = la actualización Draft→Posted, motor y guardas incluidos	Tu botón "Contabilizar" es una sola actualización de LDS más una visualización honesta de errores; nunca reimplementes la lógica de contabilización del lado del cliente
A los usuarios sin licencia se les niegan las escrituras contables con un mensaje textual	Muestra el mensaje tal cual; ya le indica al usuario que contacte a su administrador
Los errores de DML traen texto de validación listo para el usuario	Tu toast puede mostrar el mensaje sin procesar; no se necesita una tabla de traducción de códigos de error
Los conjuntos de campos rigen los formularios empaquetados	Ajústate a ellos: construye tus editores de línea a partir de los mismos describes de conjuntos de campos, para que tu UI y el formulario empaquetado nunca discrepen sobre las columnas

Errores comunes que evitar

Error	Por qué perjudica	Haz esto en su lugar
Reconstruir el formulario de la factura porque "necesita un campo más"	Semanas de trabajo duplicando una superficie de producto ya mantenida	Los conjuntos de campos agregan el campo en minutos; crea componentes para lo que los conjuntos de campos no pueden hacer
Calcular el impuesto del lado del cliente "por capacidad de respuesta"	Tu JavaScript y el motor de contabilización eventualmente discreparán, frente a un cliente	Llama a `GlobalTaxService` a través de tu controlador; guarda en caché en el componente si hace falta
Escribir en `refin__Accounting_Transaction__c` desde un controlador	Las filas del mayor forjadas a mano son exactamente lo que las guardas existen para impedir	Crea documentos y contabilízalos; el mayor se escribe solo
Suponer que los componentes empaquetados se pueden incrustar en tu DOM	Sus targets de exposición e internos no son un contrato documentado	Compón a nivel de página Lightning; trata los LWC empaquetados como superficies de producto
Probar únicamente como administrador	Los usuarios reales chocan con FLS, conjuntos de permisos y el cupo de licencia; las rutas de error de tu componente nunca se ejercitaron	Prueba como un usuario que tenga exactamente el conjunto de permisos empaquetado que tendrá tu audiencia

Qué sigue

Extensibilidad con conjuntos de campos: la alternativa sin código que conviene revisar primero.
Desarrollo con Apex en REDA: la capa de lógica.
Integración con Salesforce Flow: el punto medio declarativo.

Documentación oficial de Salesforce Lightning Web Components es un framework estándar de Salesforce: la referencia autorizada es la Guía del desarrollador de Lightning Web Components. Los enlaces se abren en una pestaña nueva.

Preguntas frecuentes

Compón a nivel de página (regiones de Lightning App Builder) en lugar de anidar programáticamente. Los targets expuestos determinan dónde se pueden colocar los componentes empaquetados; trata sus internos como privados.

Prefiere LDS/UI API (la aplicación de seguridad ya está integrada); en controladores Apex personalizados usa consultas en USER_MODE. El paquete usa USER_MODE en las lecturas que sirven a un usuario y SYSTEM_MODE donde el motor debe ver el panorama completo sin depender del acceso del usuario en ejecución: contabilización, secuencias, acumulados. En tu propio código de interfaz, usa USER_MODE por defecto y recurre a SYSTEM_MODE solo cuando puedas explicar por qué.

Sí. Ningún conjunto de permisos empaquetado otorga acceso de clase a refin.GlobalTaxService (solo se otorgan PDFGeneratorAPI y EInvoiceTrailCreator, porque las acciones de Flow empaquetadas los llaman), así que el usuario que ejecuta la acción necesita que se lo otorgues explícitamente. Verifícalo con el conjunto de permisos real en un sandbox; el modo de falla es ruidoso e inmediato.

Si los construiste contra la superficie estable (objetos refin__ vía LDS/UI API, las clases Apex globales, la composición a nivel de página), sí, por el contrato del paquete administrado. Lo que se rompe es depender de los internos de los componentes empaquetados o de clases públicas, que es justo de lo que este artículo te sigue alejando.

Textualmente. Los mensajes de guarda están redactados como oraciones dirigidas al usuario ("This document requires approval before posting." y similares); un toast que muestre el mensaje de DML tal cual es, honestamente, la mejor experiencia de usuario, y se mantiene correcto a medida que el paquete evoluciona sus reglas.

¿Te resultó útil?