Migrar de las acciones personalizadas del usuario o elementos de menú ECB a SharePoint Framework Extensions
El SharePoint Framework (SPFx) es el modelo de desarrollo recomendado para ampliar y compilar personalizaciones de SharePoint. Si ha personalizado SharePoint con acciones personalizadas del usuario y elementos de menú personalizados del Bloque de control de edición (ECB) mediante SharePoint Feature Framework, ¿cuál es la ventaja de migrarlos a SPFx?
En primer lugar, presentaremos las opciones disponibles al desarrollar extensiones de SharePoint Framework (SPFx):
- Personalizador de aplicaciones: se amplía la interfaz de usuario "moderna" nativa de SharePoint agregando elementos HTML personalizados y código del lado cliente a los marcadores de posición predefinidos de páginas "modernas". Para más información sobre los personalizadores de aplicaciones, vea Compilar la primera extensión de SharePoint Framework (parte 1 de Hello World).
- Conjunto de comandos: agregue elementos de menú ecb personalizados o botones personalizados a la barra de comandos de una vista de lista para una lista o una biblioteca. Puede asociar cualquier acción del lado cliente a estos comandos. Para más información sobre los conjuntos de comandos, vea Compilar la primera extensión del conjunto de comandos de ListView.
- Personalizador de campo: permite personalizar la representación de un campo en una vista de lista con elementos HTML personalizados y código del lado cliente. Para más información sobre los personalizadores de campo, vea Compilación de la primera extensión de Personalizador de campo.
Dependiendo de cuál sea el destino de la personalización, podrá aprovechar alguna de las versiones anteriores. Por ejemplo, los personalizadores de aplicaciones son una excelente alternativa a las acciones de usuario personalizadas. Los conjuntos de comandos son un reemplazo adecuado para los elementos de menú ECB. Por último, los personalizadores de campo están diseñados para reemplazar las personalizaciones JSLink/Client-Side-Rendering (CSR).
Ventajas de migrar personalizaciones del marco de características de SharePoint existentes a SharePoint Framework
SharePoint Framework se ha creado pensando en la nueva experiencia "moderna" de SharePoint, que está disponible en los sitios de grupo "modernos" y en los sitios de comunicación "modernos", y que se dirige a cualquier dispositivo y plataforma.
Solo se admite la forma de personalizar sitios "modernos" sin script
Una de las principales ventajas de migrar personalizaciones heredadas de SharePoint Feature Framework a la SharePoint Framework es que es la única técnica admitida que tiene en sitios modernos para personalizar la interfaz de usuario.
De hecho, los sitios "modernos" tienen habilitada la marca sin script, lo que evita la ejecución de scripts insertados en la página y cualquier acción personalizada del usuario, que hace referencia a JavaScript externo o a JavaScript incrustado.
Las acciones personalizadas de usuario heredadas simplemente no funcionan en la interfaz de usuario "moderna". Las personalizaciones de ECB creadas mediante feature framework son limitadas. Solo puede definir elementos ECB que no hagan referencia a archivos JavaScript externos o que no usen llamadas JavaScript insertadas. Si realmente desea ampliar la interfaz de usuario "moderna", debe actualizar a la SharePoint Framework.
Acceso más fácil a la información en SharePoint y Microsoft 365
Otro punto fundamental a tener en cuenta es que, en el modelo heredado de acciones personalizadas del usuario y personalizaciones de ECB, no era fácil consumir contenido y datos de SharePoint. La única manera de realizar esta acción era mediante JSOM (el modelo de objetos del lado cliente de JavaScript de SharePoint) o interfaces de programación de aplicaciones de REST de bajo nivel. Además, era casi imposible consumir el conjunto completo de servicios de Microsoft 365, a menos que aprovechara de forma autónoma ADAL.JS (Biblioteca de autenticación de Azure Active Directory para JavaScript) y código JavaScript personalizado.
Ahora, con la SharePoint Framework y las extensiones de SharePoint Framework, es fácil y sencillo consumir tanto la API REST de SharePoint como Microsoft Graph. Ahora puede crear soluciones más eficaces, que pueden consumir e interactuar con el ecosistema completo de servicios proporcionados por Microsoft 365.
Similitudes entre las soluciones de SharePoint Framework y las personalizaciones del marco de características de SharePoint
Tanto las acciones personalizadas del usuario de SharePoint Feature Framework como los elementos ECB y las personalizaciones de SharePoint Feature Framework comparten algunas similitudes.
Modelo de aprovisionamiento
Tanto las extensiones de SharePoint Framework como las acciones personalizadas del usuario o las soluciones de elementos de menú ECB aprovechan un archivo de manifiesto XML, que se escribe con la sintaxis de SharePoint Feature Framework; la implementación se basa en las mismas técnicas.
Ejecutar como parte de la página
De forma similar a las acciones de usuario personalizadas y al ECB del marco de características de SharePoint, SharePoint Framework Extensions forma parte de la página. Por lo tanto, estas soluciones tienen acceso al DOM de la página y pueden comunicarse con otros componentes de la misma página. Además, los desarrolladores tienen más facilidad para hacer que sus soluciones tengan capacidad de respuesta para que se adapten a los distintos factores de forma con los que se puede mostrar una página de SharePoint, incluida la aplicación móvil de SharePoint.
Como SharePoint Framework Extensions se ejecuta como parte de la página, independientemente de los recursos a los que tenga acceso la personalización, también pueden acceder a él el resto de los elementos de la página. Es importante tener esto en cuenta al crear soluciones que se basen en el flujo implícito de OAuth con tokens de acceso de portador o que usen cookies o el almacenamiento del explorador para almacenar información confidencial. Como SharePoint Framework Extensions se ejecuta como parte de la página, el resto de los elementos de esa página pueden obtener acceso también a todos estos recursos.
Usar cualquier biblioteca para compilar sus extensiones
Al crear personalizaciones de páginas mediante acciones personalizadas del usuario, es posible que haya usado bibliotecas como jQuery o Knockout para implementar personalizaciones dinámicas y responder mejor a la interacción del usuario. Al compilar SharePoint Framework Extensions, puede utilizar cualquier biblioteca del lado cliente para enriquecer su solución, tal y como lo hacía anteriormente.
Una ventaja adicional que ofrece la SharePoint Framework es el aislamiento del script. Aunque el elemento web se ejecuta como parte de la página, su script se empaqueta como un módulo que permite que diferentes extensiones de la misma página usen una versión diferente de jQuery sin colisionar entre sí. Se trata de una característica eficaz que le permite centrarse en ofrecer valor empresarial en lugar de realizar migraciones técnicas y comprometer la funcionalidad.
Ejecutar como el usuario actual
En las personalizaciones creadas mediante acciones de usuario personalizadas y elementos de menú ECB, lo único que debía hacer para comunicarse con SharePoint era llamar a su API. La solución del lado cliente se ejecutaba en el explorador en el contexto del usuario actual y, al enviar automáticamente la cookie de autenticación junto con la solicitud, su solución podía conectarse directamente a SharePoint. No era necesaria ninguna autenticación adicional, como al usar complementos de SharePoint, para comunicarse con SharePoint.
El mismo mecanismo se aplica a las personalizaciones compiladas en SharePoint Framework, que también se ejecutan bajo el contexto del usuario actualmente autenticado y no requieren pasos de autenticación adicionales para comunicarse con SharePoint. El contexto de seguridad es el del usuario conectado actualmente, lo que implica que, desde una perspectiva de seguridad, debe tener cuidado al instalar cualquier extensión de SharePoint Framework en cualquier colección de sitios de destino.
Usar solamente el código del lado cliente
Tanto SharePoint Framework Extensions como las soluciones de elementos de menú ECB o de acciones de usuario personalizadas se ejecutan en el explorador y solo pueden contener código JavaScript del lado cliente. Las soluciones del lado cliente tienen una serie de limitaciones, como no poder elevar permisos en SharePoint o llegar a las API externas que no admiten la comunicación entre orígenes (CORS) o la autenticación mediante flujo implícito de OAuth. En tales casos, la solución del lado cliente podría aprovechar una API remota del lado servidor para realizar la operación necesaria y devolver los resultados al cliente.
Modelo de hospedaje autocongruente y basado en Microsoft 365
Tanto las extensiones de SharePoint Framework como las soluciones de elementos de menú ECB o acción personalizada del usuario se pueden hospedar en SharePoint Online y, finalmente, en el servicio DE CDN de Microsoft 365, evitando cualquier necesidad de servicios externos o entornos de hospedaje.
Aunque hospedar soluciones de SharePoint Framework en una red CDN ofrece muchas ventajas, no es necesario y podría elegir hospedar el código en una biblioteca de documentos de SharePoint. SharePoint Framework paquetes (archivos *.sppkg) implementados en el catálogo de aplicaciones especifican la dirección URL en la que SharePoint Framework puede encontrar el código de la solución. No existen restricciones con respecto a lo que debe ser la dirección URL, siempre que el usuario que examine la página con la extensión pueda descargar el script desde la ubicación especificada.
Microsoft 365 ofrece la funcionalidad de red CDN pública que le permite publicar archivos de una biblioteca de documentos de SharePoint específica en una red CDN. La red CDN pública de Microsoft 365 logra un buen equilibrio entre las ventajas de usar una red CDN y la simplicidad de hospedar archivos de código en una biblioteca de documentos de SharePoint. Si a su organización no le importa que sus archivos de código estén disponibles públicamente, el uso de la red CDN pública de Microsoft 365 es una opción que merece la pena tener en cuenta.
Diferencias entre las soluciones de SharePoint Framework y las personalizaciones del marco de características de SharePoint
Sin embargo, entre los dos modelos de desarrollo también hay algunas diferencias significativas que debe tener en cuenta al diseñar la arquitectura de sus soluciones.
Ejecutar en sitios sin scripts
Dado que SharePoint Framework soluciones, incluidas las extensiones, se implementan a través del catálogo de aplicaciones con una aprobación previa, no están sujetas a las restricciones de no script y funcionan en todos los sitios "modernos".
Conjunto predefinido de puntos de extensibilidad
Aunque una acción personalizada del usuario puede insertar código JavaScript que puede actualizar o cambiar el DOM de cualquier parte de la página, una extensión de SharePoint Framework solo puede personalizar las áreas admitidas de las páginas "modernas".
En teoría, podría crear un personalizador de aplicación que mediante DOM pudiera cambiar por completo la estructura de una página, justo como con las acciones de usuario personalizadas. SharePoint Framework promueve un enfoque más estructurado y fiable para personalizar SharePoint. En lugar de usar elementos DOM específicos para personalizar SharePoint, SharePoint Framework proporciona a los desarrolladores enlaces y marcadores de posición específicos para las personalizaciones y debería usar solo esos.
Usar TypeScript para compilar soluciones más sólidas y fáciles de mantener
Al crear personalizaciones con las acciones personalizadas del usuario o los elementos de menú ECB, los desarrolladores suelen usar JavaScript. Estas soluciones no solían contener pruebas automatizadas, por lo que refactorizar el código era una operación propensa a errores.
SharePoint Framework permite a los desarrolladores beneficiarse del sistema de tipos TypeScript para compilar soluciones. Gracias al sistema de tipos, se detectan muchos errores durante el desarrollo en lugar de en tiempo de ejecución. Además, es más fácil refactorizar el código, ya que los cambios en el código están protegidos por TypeScript. Puesto que todo el JavaScript es TypeScript válido, la barrera de entrada es baja y puede migrar su JavaScript a TypeScript gradualmente, lo que facilita aún más el mantenimiento de su solución.
No hay acceso al modelo de objetos de JavaScript de SharePoint de forma predeterminada
Al crear personalizaciones de cliente para la experiencia del usuario clásica de SharePoint, muchos desarrolladores utilizaban el modelo de objetos de JavaScript (JSOM) para comunicarse con SharePoint. JSOM les ofrecía IntelliSense y fácil acceso a la API de SharePoint, de forma similar al modelo de objetos del lado cliente (CSOM). En las páginas clásicas de SharePoint, la parte principal de JSOM estaba presente en la página de forma predeterminada y los desarrolladores podían cargar fragmentos adicionales para, por ejemplo, comunicarse con SharePoint Search.
La experiencia del usuario de la versión moderna de SharePoint no incluye SharePoint JSOM de forma predeterminada. Si bien los desarrolladores pueden cargarlo ellos mismos, la recomendación es utilizar la API de REST o la Biblioteca principal de JavaScript de modelos y procedimientos de SharePoint (Biblioteca de JS de Pnp), que internamente utiliza la API de REST de SharePoint. REST es más universal e intercambiable entre las diferentes bibliotecas del lado cliente, como jQuery, Angular o React.
Microsoft ya no invierte activamente en JSOM. Si prefiere trabajar con una API, en su lugar podría usar la biblioteca de PnP JS, que ofrece una API fluida y escrituras de TypeScript.
Migrar una personalización existente a SharePoint Framework Extensions
La migración de personalizaciones existentes a SharePoint Framework Extensions ofrece muchas ventajas tanto a usuarios finales como a desarrolladores. Al considerar la posibilidad de migrar personalizaciones existentes a la SharePoint Framework, puede optar por reutilizar tantos scripts de JavaScript existentes como sea posible, o bien volver a escribir completamente la personalización mediante TypeScript.
Reutilizar scripts existentes
Al migrar las personalizaciones existentes a SharePoint Framework Extensions, puede volver a utilizar los scripts existentes. A pesar de que SharePoint Framework promueve el uso de TypeScript, puede usar JavaScript sin formato y transformarlo gradualmente en TypeScript. Si necesita admitir una solución durante un período limitado o con un presupuesto limitado, este enfoque puede resultarle apropiado.
No siempre es posible reutilizar los scripts existentes en una solución de SharePoint Framework. Por ejemplo, dada la variedad de bibliotecas de JavaScript, no hay ninguna manera fácil de determinar si los scripts existentes se pueden reutilizar en una solución de SharePoint Framework o si necesita volver a escribirlos. La única manera de determinarlo consiste en intentar mover las distintas partes a una solución de SharePoint Framework y ver si funcionan como se espera.
Volver a escribir la personalización
Si necesita admitir la solución durante un período más largo o desea hacer un mejor uso de la SharePoint Framework, o si resulta que los scripts existentes no se pueden reutilizar con el SharePoint Framework, es posible que tenga que volver a escribir completamente la personalización. Aunque es más costoso que reutilizar los scripts existentes, ofrece mejores resultados durante un período más largo: una solución que es mejor y fácil de mantener.
Al volver a escribir una personalización existente en una solución de SharePoint Framework, debe empezar teniendo en cuenta la funcionalidad deseada. Para implementar la experiencia del usuario, debe considerar el uso de Office UI Fabric para que la solución parezca parte integrante de SharePoint.