Mónica, parte de este gran equipo de trabajo, nos ha hecho el favor de crear esta sección porque controla muy bien el tema.
Solución:
Además de lo que todos han dicho …
El ayudante está diseñado para tener código compartido. Por lo tanto, podría tener código compartido por su renderizador y su controlador o por múltiples funciones de controlador. Eso debería ir en el archivo JS auxiliar.
Creo que una buena práctica es dejar que el controlador responda a los eventos, posiblemente realizar una cierta cantidad de flujo de control y delegar la lógica empresarial al ayudante como una separación de preocupaciones. También le permite reutilizar su lógica empresarial en otras partes del componente en el futuro.
El código auxiliar se puede compartir entre componentes cuando están relacionados mediante herencia. Si un componente extiende a otro, hereda el ayudante de su supercomponente y puede anularlo.
Los subcomponentes pueden llamar a métodos de controlador de supercomponente, pero eso puede quedar obsoleto en el futuro de acuerdo con la documentación en la Guía del desarrollador de componentes Lightning.
Los componentes pueden comunicarse entre sí a través de eventos para “compartir” código. Por ejemplo, si tiene un componente que maneja la escritura de errores de lógica empresarial de manera uniforme en su aplicación y maneja algún tipo de evento relacionado con el error, podría disparar un evento para activarlo y manejar un error.
Si eres más el tipo de persona visual. Siga este enlace del Blog del desarrollador de Salesforce: Descripción de los controladores JavaScript frente a los ayudantes en componentes Lightning
Esto es lo que hay debajo de este enlace:
Por Raja Rao DV | Publicado: 15 de junio de 2015
Los controladores y ayudantes de JavaScript juegan un key rol en Lightning Components Framework. Una de las primeras cosas que se preguntan las personas nuevas en el marco es: ¿Cuál es exactamente la diferencia entre los controladores de JavaScript y los ayudantes de JavaScript? Así que repasemos las diferencias entre ellos.
Para entenderlo mejor, digamos que tenemos una lista de cuentas que muestra dos componentes de la cuenta (Account.cmp). Puede verse así:
Visualmente, la lista de cuentas se parece a la Primera foto debajo. Pero mientras se ejecuta, en realidad se parece a la Segunda foto:
Cada componente del componente de la cuenta (paquete) se compone de un marcado, un controlador de JavaScript, un asistente, un renderizador y más.
Pero, mientras corres, el marco crea una instancia del controlador, una instancia del renderizador para cada componente, pero crea solo una copia del ayudante y pasa la referencia del ayudante a cada instancia del controlador y cada instancia del renderizador.
En nuestro ejemplo con dos componentes Account, el marco crea una copia del Helper y pasa la referencia de este Helper a dos controladores y dos instancias de renderizador.
Beneficios:
- Dado que Helper se comparte en todo, nos permite compartir y mantener la lógica de los controladores y los renderizadores en un solo lugar.
- También nos ayuda a mantener la lógica en Controllers y Renderers lean.
Por tanto, deberíamos intentar delegar la lógica empresarial a los ayudantes siempre que sea posible.
Por ejemplo:
En vez de:
// 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);
Haz lo siguiente:
// controller.js
callServer: function(cmp, helper)
helper.callServer();
//helper.js (shared across all instances of controllers and renderers)
callServer: function(cmp, helper)
var action = cmp.get("c.getAccounts");
$A.enqueueAction(action);
// renderer.js
afterRender: function(cmp, helper)
this.superAfterRender();
helper.callServer();
Nota: Si hay varios tipos de componentes (por ejemplo, AccountItem.cmp y AccountDetails.cmp), cada tipo de componente obtendrá un ayudante propio.
Cuándo usar controladores versus ayudantes:
-
Utilice los controladores para escuchar los eventos del usuario y otros eventos como componentes, eventos de aplicaciones. Pero delegue la lógica empresarial al ayudante.
-
Realice una delegación similar en todas las funciones de Renderer (render, rerender, etc.).
-
Siempre que necesite llamar a una función de controlador desde otra función de controlador, mueva esa lógica a Helper.
Antipatrón (s):
Demasiadas funciones en el Asistente: Si se encuentra en esta situación, es hora de refactorizar el componente en subcomponentes más pequeños.
valoraciones y comentarios
Si crees que te ha resultado útil nuestro post, agradeceríamos que lo compartas con el resto desarrolladores así contrubuyes a extender esta información.