SPFX Extensions: Cómo crear un Campo Personalizado

El SharePoint FrameWork ha venido para quedarse en nuestros desarrollos. Si el año pasado Microsoft ya dio un golpe sobre la mesa anunciando el SPFX y las herramientas a utilizar, este año en el Summit empezaron a mostrar todas las novedades y algunas de ellas ya están en Preview Públicas, por lo que podemos empezar a probarlas y ver los escenarios en los que encajan.

Una de las novedades en las que más interés tenemos los desarrolladores, es la que Microsoft ha llamado: «SharePoint Framework Extensions»

¿Qué son las SharePoint Framework Extensions?

El SPFX lo único que podía realizar hasta la fecha, era la implementación de WebParts en Cliente, pero aun hay muchos aspectos que no están abordando: Custom Actions, modificación de campos personalizados (JSLink, XSLT, etc.. ) o cómo añadir nuestras personalizaciones en las listas.

Pues bien, todos estos elementos son los que han anunciado que se incorporarán al SPFX. Como hemos dicho, de momento están en Preview y no se pueden utilizar en entornos productivos. En el artículo de hoy vamos a ver cómo empezar con las Extensiones «Field Customizer» o Campos Personalizados.

¿Qué es un «Field Customizer»?

Todo desarrollador de SharePoint que se precie se ha topado con el requerimiento de modificar el estilo o el comportamiento de un campo de una lista de SharePoint. En versiones anteriores a 2013 se hacia de una forma «artesanal», entrando en el formulario y añadiendo nuestro código de la mejor manera posible.

En la versión 2013 se introdujo un nuevo concepto para intentar gobernar esta «inyección» de código. El invento se llamo JSLink.

Con JSLink se pueden hacer cosas muy chulas, pero en algunos escenarios su comportamiento no es el deseado y se producen errores que no se pueden controlar. Ahora, con la salida de las SPFX, el equipo de producto ha querido estandarizar en la medida de lo posible el desarrollo con el mismo tooling de herramientas y lenguaje de programación: Visual Studio Code, NodeJS, TypeScript, Gulp, Yeoman, etc.

Manos a la obra 

Utilizando la plantilla de Yeoman habilitada para ello pondremos la siguiente instrucción:

yo @microsoft/sharepoint

NOTA: En el equipo de producto de la primera versión hay un error en el versionado. Dependiendo de si ejecutas el comando en una carpeta que ya tiene node-modules instalados, es posible que no funcione. Mi consejo es que actualices la plantilla de @microsoft/sharepoint desde el propio Yeoman. Para ello, pones el comando Yo y seleccionas la opción de actualizar una de las plantillas

Una vez ejecutamos la instrucción Yo seleccionaremos la opción Extensions(Preview). Dentro de esta pantalla tendremos tres opciones: Application Customizer, Field Customizer, ListView Command Set. En nuestro caso seleccionaremos Field Customizer (las otras dos opciones ya las veremos en los siguientes artículos).

A continuación, nos indicarán que vamos a utilizar ReactJS o ningún framework JavaScript. Este es uno de los primeros cambios respecto a los WebParts, en los que teníamos más frameworks JS disponibles.

Esto no quiere decir que no se puedan utilizar, sin embargo, todos los esfuerzos que el equipo de producto hace en SPFX, es utilizando ReactJS. Respecto a  los WebParts, mi opinión es que ReactJS no es la única alternativa posible, por lo tanto, para equipos de desarrollo que estén utilizando otro framework, no es necesario el aprendizaje de ReactJS.

En el caso de las Extensions, creo que  sobre una ingeniería de los mismos es perjudicial y por eso mismo, la utilización de librerías ligeras se adapta mejor a las necesidades que podamos tener. Por este motivo, ReactJS puede ser una opción mejor que utilizar otros frameworks  más pesados.

Una vez tenemos creada la plantilla, vamos a la ubicación desde donde se ha creado la extensión, y observamos que se ha creado una carpeta con su nombre  y el de su fichero typescript.

Este fichero ts, tiene una clase que hereda de BaseFieldCustomizer<IProps> (esta es la clase que se ha creado para la inyección de las extensions). En esta clase para nuestros desarrollo tendremos que sobreescribir tres métodos onInit, onRenderCell y OnDisposeCell.

En nuestro ejemplo, en el método onRenderCell (cuando se renderice el campo) añadiremos nuestro desarrollo. En nuestro campo vamos a renderizar un campo en formato de Slider.

Para ello pondremos este código

  @override
  public onRenderCell(event: IFieldCustomizerCellEventParameters): void {

    const value: string = event.cellValue;
    const id: string = event.row.getValueByName('ID').toString();
    const hasPermissions: boolean = this.context.pageContext.list.permissions.hasPermission(SPPermission.editListItems);
    
    const sliderField: React.ReactElement<{}> =
      React.createElement(SliderField, { value: value, id: id, disabled: !hasPermissions, onChange: this.onSliderValueChanged.bind(this) } as ISliderFieldProps);
    ReactDOM.render(sliderField, event.cellDiv);
  }

Este código  obtiene el valor de la celda, consigue el identificador del elemento y crea un elemento de React llamado SliderField. Este componente tiene el siguiente código:

export default class SliderField extends React.Component<ISliderFieldProps, ISliderState> {
constructor(props: ISliderFieldProps, state: ISliderState) {
    super(props, state);
    const intVal = parseInt(props.value);
    this.state = {
      value: isNaN(intVal) ? null : intVal
    };
  }
  @override
  public componentDidMount(): void {
    Log.info(LOG_SOURCE, 'React Element: SliderField mounted');
  }

  @override
  public componentWillUnmount(): void {
    Log.info(LOG_SOURCE, 'React Element: SliderField unmounted');
  }
  @override
  public render(): React.ReactElement<{}> {
    return (      


<div className={styles.cell}>
        {this.state.value &&
        (
          <ReactSlider value={this.state.value} max={100} onChange={this.onChange.bind(this)} disabled={this.props.disabled} />
        )}
      </div>


    );
  }
  private onChange(value: number): void {
    if (this.props.onChange)
      this.props.onChange(value, this.props.id);
  }
}

¿Cómo lo probamos?

Para los WebParts, uno de los grandes avances fue que disponíamos de un entorno en local en el cual podíamos hacer nuestras pruebas sin tener instalado un SharePoint, cosa que  facilita mucho la vida a los desarrolladores. Ahora bien, para las Extensions no disponemos de un entorno en local, por lo que tendremos que levantar el servidor NodeJS en local e ir a nuestro servidor de SharePoint Online, a la biblioteca donde queremos probar este campo y por último,  añadir la siguiente url:

loadSPFX=true&debugManifestsFile=https://localhost:4321/temp/manifests.js&fieldCustomizers={«Field»:{«id»:»0e3d8b71-56aa-4405-9225-f08a80fc1d71″,»properties»:{«sampleText»:»Hello!»}}}

De esta url tendremos que modificar el valor Field por el nombre de nuestra columna personalizada, y el id de la extensión dentro del Catalogo de Producto. Este identificador lo podemos obtener mirando el manifiesto de la propia solución.

Para facilitar la depuración de nuestras soluciones, varios miembros de la comunidad han creado una tarea de Gulp que nos genera esta url con los valores de nuestra solución. Para más información sobre esta tarea os recomiendo  pinchar en este enlace.

¿Cómo lo desplegamos en nuestro tenant?

Ahora mismo, este es el aspecto más flojo y en el que más esfuerzo debemos hacer  antes de  ponerlo en entornos Productivos. Los pasos que hay que seguir, son:

1.- Subir la App a nuestro catálogo de aplicaciones.
2.- Subir el desarrollo al CDN
3.- Instalar la App en el Site Collection.
4.- Actualizar el CliendSideID en el campo que queremos aplicarle esta personalización. Esto mediante desarrollo.

El equipo de producto está trabajando en una API para poder tener un ciclo de vida más acorde a un desarrollo moderno y que no se vuelva a incurrir en errores como en las primeras versiones de SharePoint.

Resumen

Las SPFX Extensions son un gran avance para la incorporación de los Modern Site en las nuevas Intranet y un espaldarazo definitivo para volver a incorporar a SharePoint Online como uno de los productos esenciales en las organizaciones.

En posteriores artículos abordaremos los otros tipos de «Extensions» de los que disponemos.