Este documento describe los Lightning Components de Salesforce. Los Lightning Components son componentes reutilizables que permiten construir aplicaciones frontend con tecnología JavaScript. Ofrecen una alternativa a Visualforce para crear experiencias de usuario más interactivas e inmersivas aprovechando el modelo de componentes. Los Lightning Components pueden insertarse en aplicaciones de Salesforce como en sitios externos y son altamente configurables. Sin embargo, su desarrollo es más complejo que Visualforce debido al uso de eventos asíncronos y al framework Aura subyacente.

1. Salesforce Zaragoza
Developer Group
Lightning Components
Viernes 9 de abril de 2016
David Carnicer
@tangerinelies

2. Pero, ¿qué son los
Lightning Components?

3. ¿Qué son los Lightning Components?

4. ¿Qué son los Lightning Components?
• Son la respuesta de Salesforce a la nueva ola de frameworks MVC JS
como Angular, Ember, React, etc.
• Utilizan una implementación del framework Aura, que es Open Source, un
framework orientado a componentes (no MVC per-sé).
• Trasladan parte de la lógica que de manera clásica estaba en el backend
al frontend, es decir, traen Salesforce al siglo XXI. Entregas una
aplicación al front y el servidor se olvida.
• Son componentes empaquetados que pueden ser insertados en
práticamente cualquier sitio: dentro de SF (Apps, SF1, Comunidades) y
fuera (Lightning Out).
• Son altamente reutilizables, aunque dependerá de lo buen programador
que seas ;)
• Hay componentes standard que da SF y componentes custom que tú
mismo te creas y otros que puedes descargar de AppExchange.

5. ¿Qué son los Lightning Components?

6. ¿Qué son los Lightning Components?

7. Que tampoco se flipen…
• El debugging es infernal (console.log a dolor en una
aplicación basada en eventos (asincronismo), debugging;
statement).
• Código minificado y precompilación usando closures JS
• LockerService ha hecho algo más complejo el desarrollo y ha
hecho revisar cosas ya hechas.
Y AÚN ASÍ SIGUEN MOLANDO INFINITO

8. Lightning vs. Visualforce
PERO QUÉ ESPERABAS
BIBA LAIGHGHGHNTNING

9. Lightning vs. Visualforce
Visualforce Lightning
Generacion de la UI
Servidor Cliente
Workflow
1. Usuario pide página
2. El servidor ejecuta el código back y envía el
HTML al cliente
3. El navegador renderiza el HTML
4. Cuando el usuario interactúa con la página se
vuelve al paso 1.
1. Usuario pide aplicación o componente
2. Se devuelve todo el bundle al cliente
3. El navegador carga el bundle al completo
4. La App JS genera toda la UI
5. Cuando el usuario interactúa con la página, la
app JS modifica la interfaz.

10. Lightning vs. Visualforce
Visualforce Lightning
Ventajas
• Modelo de funcionamiento comprobado
• Fácil de implementar
• Grandes aplicaciones en pequeñas páginas
mantenibles
• Integración total y directa con modelo de
metadatos de SF.
• Experiencias de usuario inmersivas y muy
interactivas
• Tu interfaz custom se alinea con la estrategía
de interfaz de Salesforce (Lightning
Experience)
Desventajas
• Interactividad limitada
• Latencias altas dependiendo de tu red y de la
cantidad de operaciones con el back, etc.
• Curva de aprendizaje dura si no se conoce el
framework o alguno equivalente
• Mayor complejidad que visualforce debido a que se
construye una aplicación y no una página (manejo
de eventos y otros)
• Lightning está en beta aún y hay cosas que
simplemente no están listas para salir (soporte
librerías JS externas).
• La cantidad de componentes standard es muy
limitada

11. Pero…
Johnny, seria increíble poder unir los dos
mundos.
Quiero exponer un dashboard del superBI de
Salesforce llamado Wave, muchas páginas
legadas que no estoy dispuesto a rehacer y a las
que le tengo cariño y a mi gato le gusta verme
poner tags HTML como si no hubiera mañana

12. BAM!
BETASAFE HARBOR
READY TO GO?
¿Y LA DOCU?

13. Visualforce & Lightning les trae amor
QUE NO PANDA EL CÚNICO:
- Hay un módulo de Trailhead que mola
para aprender a usarlo.
- Salesforce va a poner bastante
atención a este tema por el tema de los
sistemas legados.
- Juntas lo mejor de los dos mundos.
- Puedes usar Visualforce como simple
contenedor de apps, embeberlo en un
Lightning Component y a funcionar.

14. ¿De qué se compone un Lightning
Component?
Helper
Controller
Style
Documentation
Renderer
Design
SVG
Component

15. Component
• Sintaxis tipo HTML aunque con limitaciones.
• Uso de tags propios de Aura (input boxes, outputs y mil movidas más)
• No se puede incorporar código JS si no es en el Controller o en el Helper (olvídate de los alerts, pillín)
• Se especifican los imports de recursos externos (Static Resources) mediante la etiqueta <ltng:require>
• Hay modificadores de comportamiento del componente (uso en comunidades…)
• Se especifican los eventos que el componente lanza o escucha
• Se pueden anidar componentes (standard o custom)
• Declaración de atributos y eventos a recibir y escuchar.

16. Controller
• Controlador dentro de una estructura de Modelo-Vista-Controlador de frontend
• Código JS con gran componente asíncrona. Necesario comprender funcionamiento de JS ”BIEN”
• Se recomienda que en el Controller solo se implemente la lógica de funcionamiento del componente.
• Resto de operaciones irán en el Helper.

17. Helper
• Resto de código JS, generalmente, relacionado con funcionamiento de librerías externas.

18. Style
• Hoja de estilo CSS. Se puede utilizar para modificar cualquier parte del componente.
• THIS es una de las particularidades del framework y se refiere al propio componente

19. Otros
• Documentation: documentación para la documentación de Aura
que es autogenerada. Muy recomendable rellenar la información
cada vez que se genera un componente puesto que la web que se
genera sobre Aura es buena a la hora de consultarla.
• Renderer: Para modificar el comportamiento del renderer por
defecto del componente. Código JS.
• Design: Utilizado para exponer parámetros a los operadores que
introduzcan el componente. De este modo se puede modificar el
comportamiento del componente sin tener que modificar su código.
• SVG: Utilizado para gráficos de uso en el componente.

20. Comunicación entre componentes
• Comunicación mediante eventos.
• Distintas tipologías.
• Event Bubbling.

21. Comunicación entre componentes
• Sistema de eventos de distintas tipologías (aplicación,
componente).
• Son como un autobús que transporta cosas. Sale de una
estación y llega a todas las otras de su número.
• Conviene tener bien acotados todos los eventos de los
componentes de una página para que la ejecución no sea
incontrolable.

22. Espero que no sea tan horrible como
Visualforce…

23. Salesforce Lightning Design System
• Salesforce esta yendo hacia una estrategia de unificar las UI
de todos los desarrollos de todos los tipos. Para eso sacaron
SLDS.
• Es un framework CSS que proporciona componentes para
poder reutilizar en cualquier tipo de desarrollo web de
cualquier plataforma.
• También proporciona ayudas a nivel de diseño, lettering,
colores, etc.
• Es open source y lo puedes descargar de GitHub o
https://www.lightningdesignsystem.com/

24. ¿Cuándo uso uno u otro?

25. Usa Lightning si…
• Si estás desarrollando una app SF1, Lightning mola porque Visualforce tiene un modelo
no adecuado para aplicaciones móviles debido a que las malas redes de datos móviles
producen altas latencias. Lightning sin embargo en eso es el rey.
• Si quieres hacer una UX super chanante con una app muy interactiva con multitud de
animaciones y cosas guays, usa Lightning.
• Si quieres que admins, operadores o monos borrachos creen aplicaciones
ensamblando componentes (por ejemplo en Community Builder y App Builder) en plan
drag-drop esto les encantará porque estan bien empaquetados y son tan configurables
como tú los piques.
• Si quieres empezar a trastear con “el futuro” para que el día que sea ”el presente”,
empieza con Lightning.
• Si estás empezando un proyecto nuevo, seguro que a tu cliente le encantan las
filigranas y volteretas de su UI, el bajo time to market, la disminución de horas en las
estimaciones que les vas a cobrar por su alta reutilización…
• APROVECHA LA HERENCIA! ES LO QUE LOS HACE REUTILIZABLES

26. Usa Visualforce si…
• Si te va el rollo old-style porque te sientes cómodo y porque lo manejas
genial y quieres construir una experiencia page-centric, usa VF.
• Si un día te casaste con Angular y le haces ojitos a React, usa VF.
• Si quieres hacer una experiencia interactiva con algún framework
específico (Sencha y esos rollos), usa VF como contendor.
• Si quieres exponer un sitio web sin autenticación para el público, usa
VF debido a que los componentes lightning no soportan contextos
anónimos.
• Los lightning components no se llevan bien con la renderización de
páginas como PDF aún.
• Si tienes que añadir cosas a un proyecto que ya tiene mucho hecho en VF
pages. De todos modos considera que en poco tiempo estarás
desarrollando para un sistema legado.

27. Cosas nuevas que han metido últimamente
• Lightning CLI (ES Lint) para auditar el código de los Lightning
Components.
• Lightning Data Service
• Eventos nuevos
• Lightning Out
• Lightning Tokens
• Mejor integración con merge fields.

28. Coloquio
• ¿Alguien ha desarrollado con Lightning Components?
• ¿Qué opináis de sus capacidades y manejo respecto a
Visualforce?
• ¿Cuáles creéis que son las fortalezas de los Lightning
Components?
• ¿Qué opináis de la alta reutilización de los componentes y de
poder usarlos en cualquier sitio?
• ¿Os gustaría hacer un taller poniéndonos a hacer código?

29. David Carnicer
@tangerinelies
¿Alguna pregunta más?