Migrar personalizaciones de JSLink a los personalizadores de campo de SharePoint Framework
El SharePoint Framework (SPFx) es el modelo recomendado para ampliar y compilar personalizaciones de SharePoint. Si ha personalizado campos de SharePoint y vistas de lista con JSLink, es posible que se pregunte cuál es la ventaja de migrar estas personalizaciones a SPFx.
En primer lugar, se presentan las opciones disponibles al desarrollar extensiones de SharePoint Framework:
- 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 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 campo son una buena alternativa a las personalizaciones de campos de JSLink.
Sugerencia
Aunque los personalizadores de campos son la ruta de migración natural de JSLink, también debe evaluar mediante el formato de lista y columna para personalizar la vista de lista. Ambas tecnologías tienen sus ventajas y desventajas individuales y una puede ser más sencilla de implementar y mantener que la otra en función de su escenario.
Puede obtener más información aquí: Usar el formato de columna para personalizar SharePoint
Ventajas de migrar las personalizaciones de JSLink existentes a SharePoint Framework
El SharePoint Framework se creó para ampliar la experiencia "moderna" de SharePoint. La experiencia "moderna" está disponible en los sitios de equipo "modernos" y en los sitios de comunicación "modernos", y que tiene como destino cualquier dispositivo y cualquier plataforma.
Es la única manera admitida de personalizar bibliotecas y listas "modernas"
Una de las principales ventajas de migrar personalizaciones de JSLink heredadas a la SharePoint Framework es que es la única opción admitida disponible. De hecho, las listas y bibliotecas "modernas", debido a su infraestructura de representación y a la marca sin script habilitada en los sitios "modernos", no pueden basarse en personalizaciones de JSLink heredadas. Si realmente desea ampliar la interfaz de usuario "moderna", debe migrar la solución JSLink a un personalizador de campo SharePoint Framework.
Acceso más fácil a la información en SharePoint y Microsoft 365
Otro tema fundamental a tener en cuenta es que en las personalizaciones de JSLink heredadas no era fácil consumir contenido y datos de SharePoint. La única manera de hacerlo era usar el modelo de objetos del lado cliente (JSOM) de JavaScript o las API REST de bajo nivel. Era casi imposible consumir el conjunto completo de servicios de Microsoft 365 a menos que usara ADAL.JS (Biblioteca de autenticación de Azure Active Directory para JavaScript) y código JavaScript personalizado.
Ahora, con las extensiones SharePoint Framework y 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 personalizaciones de JSLink como las personalizaciones de SharePoint Feature Framework comparten algunas similitudes.
Modelo de aprovisionamiento
Tanto las extensiones SharePoint Framework como las acciones personalizadas del usuario o las soluciones de elementos de menú ECB usan un archivo de manifiesto XML, que se escribe con la sintaxis de SharePoint Feature Framework. Por lo tanto, la implementación se basa en las mismas técnicas. Sin embargo, con los nuevos personalizadores de campo puede personalizar la representación de un campo, y no la representación de una sola vista de una lista o biblioteca. El campo personalizado se puede usar en tantas listas y bibliotecas como desee.
Ejecutar como parte de la página
De forma similar a las acciones personalizadas del usuario y ECB de SharePoint Feature Framework, las extensiones de SharePoint Framework forman 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.
Dado que SharePoint Framework extensiones se ejecutan como parte de la página, a cualquier recurso al que tenga acceso la personalización, también pueden acceder otros 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. Dado que SharePoint Framework extensiones se ejecutan como parte de la página, otros elementos de esa página también pueden acceder a todos estos recursos.
Usar cualquier biblioteca para compilar sus extensiones
Al crear personalizaciones de páginas mediante acciones de usuario personalizadas, puede que haya utilizado bibliotecas como jQuery o Knockout para que la personalización sea dinámica y responda mejor a la interacción del usuario. Al compilar extensiones de SharePoint Framework, puede usar cualquier biblioteca del lado cliente para enriquecer la solución, de la misma manera que lo habría hecho en el pasado.
La ventaja adicional que le ofrece SharePoint Framework es el aislamiento del script. Aunque el elemento web se ejecuta como parte de la página, el script se empaqueta como un módulo, lo que permite, por ejemplo, que las diferentes extensiones de una misma página utilicen una versión diferente de jQuery sin colisionar unas con otras. 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 JSLink, 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 las extensiones de SharePoint Framework como las personalizaciones de JSLink 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 los archivos de JavaScript para personalizaciones de JSLink 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 de JSLink
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 y en bibliotecas y listas "modernas"
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". Como ya vimos, los personalizadores de campo de SharePoint Framework funcionan en listas y bibliotecas "modernas", mientras que el JSLink heredado no.
Los personalizadores de campo admiten los escenarios solo con permiso de visualización
Puede usarse una personalización de JSLink para personalizar no solo la vista de un campo en una lista o biblioteca, sino también la visualización y editar vistas de un campo mientras se muestra un solo elemento.
En el momento de escribir este artículo, un personalizador de campo de SharePoint Framework puede personalizar la representación de un campo solo en el modo de representación de la vista de lista, mientras que en las vistas de visualización y edición de un solo elemento no se puede aprovechar la personalización.
Usar TypeScript para compilar soluciones más sólidas y fáciles de mantener
Al crear las personalizaciones con JSLink, los desarrolladores utilizan a menudo JavaScript simple. 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, los errores se detectan 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 compilar personalizaciones del lado cliente para la experiencia de usuario clásica de SharePoint, muchos desarrolladores usaron el JSOM para comunicarse con SharePoint. El JSOM les ofreció IntelliSense y un fácil acceso a la API de SharePoint de forma similar al modelo de objetos Client-Side (CSOM). En las páginas clásicas de SharePoint, la parte principal del JSOM estaba presente de forma predeterminada en la página y los desarrolladores podían cargar piezas adicionales para comunicarse con La búsqueda de SharePoint, por ejemplo.
La experiencia del usuario de la versión moderna de SharePoint no incluye SharePoint JSOM de forma predeterminada. Aunque los desarrolladores pueden cargarla por sí mismos, la recomendación es usar la API REST en su lugar, o la biblioteca principal de JavaScript de patrones y prácticas de SharePoint (PnPJS), que usa internamente la API REST de SharePoint. REST es más universal e intercambiable entre las diferentes bibliotecas del lado cliente, como jQuery, Angular o React.
Microsoft no está invirtiendo activamente en el JSOM. Si prefiere trabajar con una API, puede usar la biblioteca de PnP JS, que ofrece una API fluida y declaraciones de tipo TypeScript.
Migración de la personalización existente a las extensiones de SharePoint Framework
La migración de personalizaciones existentes a las extensiones de SharePoint Framework ofrece muchas ventajas tanto a los usuarios finales como a los 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 las extensiones de SharePoint Framework, puede optar por reutilizar 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 diversidad de bibliotecas de JavaScript, no hay una forma fácil de saber por adelantado si pueden reutilizar los scripts existentes en una solución de SharePoint Framework o tendrá que volver a escribirla. 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 con un mejor rendimiento y más fácil de mantener y usar.
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.