Arquitectura, buenas prácticas y desarrollo sobre la nueva herramienta de Microsoft SharePoint 2016

SPFX: Entendiendo la utilización de Recursos

La semana pasada se anuncio la disponibilidad General del SPFX  en todos los tenant de Office 365. A día de hoy  ya podemos ponerlo en entornos productivos, así que vamos a aprovechar esta cicunstancia para tratar de entender cómo funciona la solución del tema de Recursos que trae de serie SPFX y de esta forma, evitar algún error en este sentido.

Introducción

Antes de empezar a ver el funcionamiento de los recursos multiidioma, vamos  e explicar el funcionamiento que esperamos que tenga.

Cuando en un desarrollo ASP.NET hacemos uso de un fichero de recursos o en un desarrollo JavaScript utilizamos una librería como i18n , lo que esperamos es tener un fichero genérico con el idioma habitual de nuestra aplicación.  En caso de que nuestra aplicación soporte otro idioma, agregamos otro fichero: bien resx, bien .json (con la extensión del idioma que soporta), y él mismo se encarga de traducir nuestra aplicación.

En caso de que no dispongamos del fichero de recursos de un idioma, devolverá la aplicación en el idioma por defecto.

Tal y como funciona SPFX, cuando creamos un proyecto (>yo @microsoft/sharepoint) en el WebPart disponemos de un fichero de “recursos” por defecto. Está  ubicado en  la carpeta “src->webparts->resource->loc”. Dentro de esta carpeta hay dos ficheros:

  • mystrings.d.ts donde estarán almacenados el nombre para acceder a los recursos
  • en-us.js donde esta la traducción de los recursos indicados en el fichero anterior.

Para poder utilizar los recursos dentro de nuestro código, bastará con importar la clase mystring de la siguiente forma:

import * as strings from 'resourceStrings';

Para utilizarlo dispondremos de intelisense, en el cual tendremos todos los recursos disponibles.

Vamos a ver un ejemplo básico. Vamos al load de la clase de WebPart y añadimos en el html que nos muestre el contenido de uno de estos elementos del fichero de recursos tal que quede de la siguiente forma:

  public render(): void {
    this.domElement.innerHTML = strings.BasicGroupName + `
      <div class="${styles.helloWorld}">

<div class="${styles.container}">

<div class="ms-Grid-row ms-bgColor-themeDark ms-fontColor-white ${styles.row}">

<div class="ms-Grid-col ms-u-lg10 ms-u-xl8 ms-u-xlPush2 ms-u-lgPush1">
              <span class="ms-font-xl ms-fontColor-white">Welcome to SharePoint!</span>
              Customize SharePoint experiences using Web Parts.
${escape(this.properties.description)}
              <a href="https://aka.ms/spfx" class="${styles.button}">
                <span class="${styles.label}">Learn more</span>                
              </a>
            </div>
          </div>
        </div>
      </div>
`;
  }

Si arrancamos nuestra solución dentro del Workbench local funcionará correctamente:

A continuación, esta misma solución la desplegamos en un Tenant de Office 365 y ¿cuál es el resultado? Por lo que podéis deducir, esta claro que va a fallar…

¿Por qué falla?

Analicemos como funciona SPFX.

Si vamos al fichero de configuración de la solución ubicado dentro de la carpeta Config-> Config.json, vemos que ese documento tiene un nodo, que es “localizedResources”. En este nodo está la ubicación de los ficheros de recursos de cada WebPart, en los cuales el parámetro es el idioma en el que se ejecuta.

{
  "localizedResources": {
    "resourceStrings": "webparts/resource/loc/{locale}.js"
  }
}

En en base a este funcionamiento, si utilizamos el sistema de recursos por defectos que trae SPFX, en caso de que despleguemos un WebPart y el cliente lo visualice en un idioma en el que no tengamos creado, en ese fichero se producirá un error.

¿Por qué no falla en el Workbench?

El motivo de por qué en el Workbench NO falla, es porque en el mismo, se está cargando la página como si se estuviera cargando en idioma americano. ¿Cómo lo sabemos? Nos vamos a la carpeta /temp/ y abrimos el fichero workbench.html y observamos que se carga como si estuviéramos en un navegador americano.

<!doctype html>
<html dir="ltr">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta http-equiv="X-UA-Compatible" content="IE=edge" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />

  <title>SharePoint Web Part Workbench</title>

  <link rel="shortcut icon" href="https://localhost:4321/node_modules/@microsoft/sp-webpart-workbench/dist/assets/server-icon.png" />

  <script type="text/javascript" src="https://localhost:4321/temp/manifests.js"></script>
  <script type="text/javascript" src="https://localhost:4321/node_modules/@microsoft/sp-loader/dist/sp-loader_en-us.js"></script>
  <script type="text/javascript" src="https://localhost:4321/node_modules/@microsoft/sp-webpart-workbench/lib/api/workbenchInit.js"></script>
</head>
<body>

  <script type="text/javascript">
    window.spModuleLoader.start(window.preloadedData);
  </script>
</body>
</html>

Conclusión

Aunque en un principio, la solución que se ha propuesto para solucionar el tema del multi idioma dentro de un WebPart parece una solución pensada y meditada, mi opinión es que tiene que mejorar y abordar el supuesto de que haya un idioma por defecto.

Office 365 da soporte a todos los lenguajes disponibles y en el SPFX creo que se debería haber optado por una solución como la de las Add-In. En los Add-In indicábamos los idiomas que soportaba y cuál era el idioma por defecto.

Otra alternativa sería que funcione como hace i18n es decir, tener un idioma por defecto, para que en el caso de que no haya traducción para ese idioma, devuelva un idioma y no un error.

En un articulo  posterior veremos cómo poder utilizar i18n y cómo solucionar ese problema.

mm

Sobre Adrián Díaz

Adrián Díaz es Ingeniero Informático por la Universidad Politécnica de Valencia. Es MVP de Microsoft en la categoría Office Development desde 2014, MCPD de SharePoint 2010, Microsoft Active Profesional y Microsoft Comunity Contribuitor 2012. Cofundador del grupo de usuarios de SharePoint de Levante LevaPoint. Lleva desarrollando con tecnologías Microsoft más de 10 años y desde hace 3 años está centrado en el desarrollo sobre SharePoint. Actualmente es Software & Cloud Architect Lead en ENCAMINA.
Esta entrada ha sido publicada en spfx, typescript y etiquetada como . Enlace permanente .
ENCAMINA, piensa en colores