Blog

En el mundo de los componentes lightning nos encontraremos con los archivos controller.js y helper.js, si quieres hacer el mejor uso o mejor dicho las mejores practicas, aquí te detallo brevemente cual es la diferencia entre uno y otro y en donde deberías colocar tus funciones.

Supongamos que contamos un componente AccountList, el cual contiene a su vez el componente AccountCmp dos veces.

<c:AccountList>
   <c:AccountCmp id="1" />
   <c:AccountCmp id="2" />
</c:AccountList>

De manera visual el componente AccountList, se mostraría como en la imagen de la izquierda, pero mientras se ejecuta, se visualiza como en la imagen de la derecha.

Cada componente (paquete) esta compuesto por un marco (color amarillo), un archivo controller.js (verde), un helper.js (rojo), un renderer.js (morado) y otros.

Pero al momento de “estar corriendo”, el framework crea una instancia del controller, una instancia del renderer para cada componente, pero crea una sola copia del helper, y pasa la referencia del helper a cada instancia del controller y renderer.

Nota importante:
En caso de que tuviésemos diferentes componentes, por ejemplo, AccountItem.cmp y AccountDetails.cmp, cada tipo de componente tendrá su propio Helper, es decir, no se comparte como en el ejemplo anterior.

Ventajas

• Dado que en Helper es compartido a traves de todos los componentes, nos permite compartir y mantener la lógica de Controllers y Renderers en un solo lugar.
• También nos ayuda a mantener la lógica dentro de Controllers y Renderers “delgados”

Por lo tanto, debemos intentar delegar la lógica empresarial a los Helpers siempre que sea posible.

Por ejemplo, en lugar de tener lo siguiente:

// controller.js
callServer: function(cmp, helper) {
   var action = cmp.get("c.getAccounts");
   $A.enqueueAction(action);
}

// renderer.js
afterRender: function(cmp, helper) {
   this.superAfterRender();
   var action = cmp.get("c.getAccounts"); 
   $A.enqueueAction(action); 
}

Deberíamos hacer lo siguiente:

// controller.js
callServer: function(cmp, helper) {
  helper.callServer();
}

//helper.js (compartido a traves de toda las instancias de controllers y renderers)
callServer: function(cmp, helper) {
   var action = cmp.get("c.getAccounts");
   $A.enqueueAction(action);
}

// renderer.js
afterRender: function(cmp, helper) {
   this.superAfterRender();
   helper.callServer();
}

¿Cuándo usar Controller vs Helper?

• Usa los Controllers para escuchar eventos de usuario y otros eventos como componentes, eventos de aplicaciones. Pero delega la lógica de negocio al Helper.
• Delegar de manera similar en todas las funciones de Renderer (render, rerender, etc.).
• Cuando necesites llamar a una función de controlador desde otra función de controlador, mueve esa lógica al Helper.

Anti-patrón

Demasiadas funciones en el Helper: si llegas a tener esta situación, lo más conveniente será refactorizar o descomponer el componente en subcomponentes más pequeños.

No es posible declarar una variable global en los componentes lightning, específicamente en los archivos controller.js y helper.js, pero podemos crear un atributo ( aura:attribute ) en el componente que puede ser usado para almacenar información y puede ser usado en el controller o en el helper de manera global.

En los componentes lightning podemos almacenar en cache (en el lado del cliente), información que queramos tener disponible rápidamente.

El término Server Action, es un método que podemos invocar remotamente desde un componente lightning, mediante
setCallback, sin embargo existe otro método o función con lo cual podemos almacenar en cache dicha respuesta, éste método es setStorable.

 
var action = component.get("c.obtenerItems");
action.setStorable();
action.setCallback(this, function(response) {
 // manejar respuesta
};
 $A.enqueueAction(action);

Cuando una acción se marca como Storable, el framework devuelve automáticamente la respuesta de la memoria caché del cliente (si la información está disponible) para que los datos estén inmediatamente disponibles para el componente para su visualización o procesamiento.

El framework puede llamar al método del servidor en segundo plano, y si la respuesta es diferente, invoca a la función Callback de acción por segunda vez.

A continuación dejo unas imágenes con cada uno de los escenarios posibles.

Este post es un simple recordatorio de como pasar una pestaña o ficha (tabs) entre ambientes de Salesforce, mediante un conjunto de cambios (Change Sets).

1. Crear un conjunto de cambios de salida, seleccionar tabs (o ficha, en idioma español)
2. Una vez cargado el conjunto de cambios, luego de validar e implementar, hay que ir a el o los perfiles, en los cuales nos interesa ver esta pestaña.

Cuando apenas te estas introduciendo al mundo de los componentes lightning de Salesforce, puede resultar difícil entender como funciona el llamado de las funciones entre componentes que bien pueden tener una relación padre-hijo o bien que no tienen relación alguna.

A continuación un breve tip de que hacer en esos casos:

1. Si quieres llamar a funciones de un componente hijo desde el padre, usa atributos (aura:attribute) o métodos (aura:method).
2. Si quieres llamar a funciones de un componente padre desde el hijo, usa Eventos de componentes (Component Events) mediante aura:handler
3. Si entre los componentes no hay relación alguna entonces deberás usar “Eventos de aplicaciones” (Application Events)

Supongamos que tienes unos registros creados por usuarios de una oficina A y el líder de la oficina B quiere ver dichos registros. Para solucionar este escenario están las configuraciones de colaboración.

2.- Haciendo scroll hacia abajo, encontrarás tanto los objetos estándar de Salesforce como los objetos personalizados (custom objects). En la imagen de abajo me posicione en el objeto personalizado “Plan de Atracción Por Periodo”.

3.- Al dar clic en nuevo podrás ver la configuración para poder compartir los registros de ese objeto.