Resumen de 2022: nuevas funciones para desarrolladores del año pasado ☁️

Para reflexionar sobre el año pasado, revisé las notas de la versión y pedí a nuestros defensores de desarrolladores su opinión sobre algunas de las mejores características de 2022. Eche un segundo vistazo a estas mejoras para ver cómo pueden mejorar su vida como desarrollador que trabaja con la plataforma de Salesforce! NOTA: En aras de la transparencia, los criterios para nuestras funciones principales incluyen: tenía que lanzarse como Generalmente Disponible (GA) en 2022 (sin funciones Beta o Piloto), y tenía que ser de alguna manera una función orientada al desarrollador (Somos bastante generosos con este). Nuevas API siguiendo estándares abiertos Durante el año pasado, se lanzaron la API Pub/Sub y la API GraphQL. Estas nuevas API presentan a los equipos de desarrollo más flexibilidad y productividad al integrarse con Salesforce. También representan un mayor avance en la adopción de estándares de la industria en el desarrollo de Salesforce. API de publicación/suscripción En el pasado, la integración basada en eventos con Salesforce requería dominar diferentes API y técnicas. La publicación, la suscripción y la introspección se realizaron utilizando diferentes API y tecnologías. Al publicar un evento, tenía que seleccionar una de varias API. Su aplicación de cliente se suscribió usando alguna biblioteca basada en el protocolo CometD. Y si querías hacer una introspección del esquema de eventos, había una API REST especial para llamar. Cambiar a la API de Pub/Sub basada en gRPC significa que necesitará una comprensión mucho menos explícita de todas estas piezas del panorama de la API de Salesforce. Al usar la biblioteca/lenguaje de gRPC de su elección, tendrá acceso a todos estos servicios basados en eventos a través de un conjunto común de interfaces. API GraphQL Desde su presentación al mundo en 2015, GraphQL ha cambiado la forma en que los desarrolladores crean aplicaciones web y móviles. Facturándose a sí mismo como una alternativa a las API REST tradicionales, su enfoque de punto final único, solicitud única para muchos datos diferentes es muy popular. Si es un desarrollador experimentado en el ecosistema de Salesforce y ha visto esto y se ha preguntado: "¿No es una especie de consulta SOQL?", tiene razón… y está equivocado. En su estado actual, dada la existencia de SOQL complejo, existe una gran cantidad de superposición con la API de GraphQL, particularmente con respecto a la consulta de múltiples objetos. Pero dos características que aún están en camino son la compatibilidad con mutaciones y el adaptador de cable GraphQL API LWC. Actualmente, para realizar una consulta ad hoc de datos en LWC, se requiere una clase de Apex. Tener soporte de consultas a través del adaptador de cable API GraphQL directamente en LWC eliminará una pieza adicional de complejidad para recuperar datos en su código LWC. Y las mutaciones (la capacidad de modificar y eliminar datos) significarán que el uso de la API de GraphQL tiene el potencial de simplificar en gran medida las aplicaciones web y móviles que se conectan con Salesforce. ¡Esté atento a que estas características lleguen pronto!

La marcha continua hacia los estándares abiertos

Hay otro gran beneficio en la introducción de estas dos API desde el punto de vista de la dotación de personal para los proyectos de integración de Salesforce. El uso de lenguajes y protocolos estándar de la industria amplía la accesibilidad de Salesforce Platform a más desarrolladores. Como desarrollador que ya conoce gRPC o GraphQL, estas API le facilitarán más que nunca la preparación para trabajar con Salesforce.

Más información sobre las nuevas API de Pub/Sub y GraphQL

Lightning Web Security: como Locker, solo que mejor

Cuando lanzamos Lightning Components en 2014, la promesa de elementos de interfaz de usuario personalizados sin el dolor de un iFrame hizo que todos los desarrolladores de Visualforce se emocionaran. Luego, la seguridad del producto de Salesforce nos trajo a todos de vuelta a la Tierra con la realidad de lo que significaría para cada desarrollador (el nuestro, el suyo, el de su proveedor de aplicaciones de AppExchange) tener acceso libre y gratuito a cada elemento DOM en la interfaz de usuario de Salesforce. Y así nació el servicio Locker .

Desde entonces, los desarrolladores han aprendido a trabajar con él, a su alrededor, y a aprovechar al máximo la creación de interfaces de usuario personalizadas. Pero los equipos de producto e ingeniería de UI se dispusieron a encontrar una mejor manera. De esa manera es Lightning Web Security (LWS).

Anteriormente, el desafío era la falta de funciones del navegador. Aparte de un iFrame, no había una forma nativa de aislar un elemento de la interfaz de usuario y evitar que se viera comprometido por otro código en el DOM. Una de las iniciativas más emocionantes en la historia reciente de Salesforce es nuestra participación activa en el proceso de estándares web y nuestra estrecha asociación con proyectos y proveedores de navegadores. A través de este enfoque cooperativo, Salesforce influye en las nuevas funciones que se introducen en los estándares web y, finalmente, en los navegadores que admiten el desarrollo con Salesforce. La propuesta de ShadowRealm es una de esas características. Agrega un objeto global, virtualizado y en espacio aislado que constituye la base de LWS.

LWS hace uso de esta función de sandboxing nativa. Esto significa que puede equilibrar mejor la seguridad con la usabilidad, el rendimiento y la integración entre los componentes de la interfaz de usuario. LWS promete brindar más flexibilidad a su trabajo de LWC a través de más bibliotecas JS disponibles. También puede haber beneficios de rendimiento para LWS sobre Locker Service.

Para habilitar LWS, vaya a Configuración > Configuración de sesión en su organización. En la mayoría de los casos, no debería requerir cambios en su código, pero esto no está garantizado (ya sea que el código sea suyo o de las aplicaciones de AppExchange). Asegúrese de habilitarlo y probarlo en un espacio aislado antes de habilitarlo en producción.

Más información sobre LWS

Ganancias de paridad de características de LWC a Aura

Lanzar una ventana modal usando LWC y hacer que su LWC muestre un flujo de pantalla han sido dos elementos importantes en el camino para lograr que Lightning Web Components tenga paridad de características con Aura.

Desde el momento en que se lanzó LWC, los desarrolladores han estado preguntando cuándo habría un LWC que proporcionara las funciones modal y popover al estilo del componente <lightning:overlayLibrary/> Aura. Bueno, no espere más: ahora puede crear componentes que se pueden usar como superposiciones modales haciendo que su módulo LWC importe y amplíe la clase JavaScript LightningModal . Esta es una característica muy nueva recién lanzada en Winter '23.

Aquí hay un ejemplo de un componente modal que usa la clase LightningModal :

Si bien Flow ha tenido una gran cantidad de características nuevas en Winter 23, quiero mencionar el componente base lightning-flow , que le permite mostrar un Flujo de pantalla de LWC. De ahora en adelante, cuando un flujo de pantalla sea la mejor manera de resolver ese problema, puede hacer que funcione en LWC.

Las publicaciones de blog para lightning-modal y para incrustar flujo en LWC acaban de publicarse en diciembre, por lo que no dedicaré mucho tiempo a repetirlas. Pero baste decir que tener estas características integradas en LWC hará que la vida de cada desarrollador sea mucho más fácil.

Más información sobre estas mejoras de LWC

La clase de afirmación

Soy un ávido ciclista de montaña. La primera vez que usé una tija de sillín con cuentagotas ajustable operada a distancia (generalmente conocida como tija con cuentagotas), cambió fundamentalmente la forma en que montaba mi bicicleta y cuánto disfrutaba al ir cuesta abajo. Moverse entre una buena altura de pedaleo y poder tener mi asiento fuera del camino de mi trasero y piernas fue la respuesta a un problema que no sabía que tenía. La clase Assert Apex es un poco así.

¿Quién sabía que tener tres métodos de afirmación completos era limitante? Quiero decir, ¿qué más necesita, sino poder hacer assert(Boolean) , assertEquals(Any, Any) , y assertNotEquals(Any, Any) ?

Resulta bastante.

La clase Assert le brinda un montón de azúcar sintáctico en forma de evaluaciones condicionales nuevas y más específicas que un desarrollador puede usar al probar su código Apex. Digamos que necesita verificar que una variable sea de un tipo específico. Eso está cubierto. ¿Quieres comprobar si hay un valor nulo? Eso también está cubierto.

Y ya no tendrá que razonar sobre cómo hacer que su condición de afirmación resulte con un valor booleano específico, ya que cada forma de evaluación viene con un método que busca una comparación true y una comparación false . Por ejemplo, verificar que la instancia sea de un tipo específico se puede hacer con isInstanceOfType() o isNotInstanceOfType() .

Como compartimos contigo en una publicación de blog reciente, puedes ver la diferencia entre las dos formas de probar un resultado.

Aquí hay un ejemplo del antiguo método System.assert() :

Y aquí hay un ejemplo con Assert.isInstanceOfType() :

Tener la intención de la prueba en el nombre del método que está utilizando para la prueba hace que las cosas sean aún más claras.

Incluso hay un método llamado fail() , que lanza una excepción de aserción sin tener que usar la técnica did-they-mean-to-do- assertEquals(false) .

Y al igual que con los métodos del sistema anteriores, cada método está sobrecargado con una firma de método que le permite escribir su propio mensaje personalizado cuando falla la afirmación.

Con todo esto, le resultará más fácil escribir pruebas de Apex y razonar sobre las pruebas de Apex que encuentra en su base de código existente.

Así que sí, tal vez no necesites la clase Assert en el sentido más puro de la palabra… tal vez yo tampoco necesitaba mi cuentagotas. Pero todos seremos más felices con ellos.

Más información sobre la clase Assert

Centro DevOps

Una buena gestión y gobierno del ciclo de vida del software puede marcar una gran diferencia entre el éxito de los proyectos y la eficiencia de los equipos. Con la combinación única de código y sin código de Salesforce, querrá una herramienta diseñada para el trabajo.

DevOps Center se diseñó teniendo en cuenta esta amplia gama de personalizaciones de aplicaciones. También atiende a una gama igual de amplia de niveles de habilidad. Ya sea que solo se trate de construir en el menú Configuración o que haya dominado la línea de comando (o cualquier otra cosa), DevOps Center es para usted.

DevOps Center está diseñado para llevar el ecosistema de Salesforce más allá de los conjuntos de cambios. Ofrece integración con GitHub, canalizaciones, integración con organizaciones de desarrollo (como sandboxes y organizaciones borrador) y muchas otras funciones. Por lo tanto, no importa cuál sea la composición de su equipo, puede razonar sobre cómo crea e implementa funciones para Salesforce.

Más información sobre DevOps Center

Menciones honoríficas

Obviamente, lanzamos demasiadas funciones en 2022 para resumirlas todas en una breve publicación de blog. Y mis selecciones se basan en mis propias impresiones y en cómo uso Salesforce. Mientras el equipo discutía qué funciones se lanzaron el año pasado, surgieron otras. Los siguientes son algunos que debería considerar investigar si aún no lo ha hecho.

Conclusión

Cada año bendice a los desarrolladores de Salesforce con nuevas funciones y desarrollos en la plataforma. El lanzamiento regular de nuevas funciones es una de las cosas que atrae a muchos desarrolladores para trabajar con Salesforce. ¿Y usted? ¿Cuáles son tus características favoritas de 2022? Si desea compartir, asegúrese de anunciarlo en las redes sociales y mencionarnos en Twitter o LinkedIn .

Sobre el Autor

Peter es un defensor de los desarrolladores y se ha centrado en la habilitación de desarrolladores durante 20 años. Dirige el equipo de defensores de desarrolladores de Salesforce Platform en América del Norte y EMEA. Encuéntralo en Twitter: @pchittum.