Partager via

Migrer les personnalisations existantes du composant WebPart d’éditeur de script vers SharePoint Framework

  • Article

SharePoint Framework est un modèle pour la création de personnalisations SharePoint. Si vous avez créé des solutions SharePoint côté client à l’aide du composant WebPart Éditeur de script, vous pouvez vous demander quels sont les avantages de leur migration vers SharePoint Framework.

Cet article présente les avantages de la migration de personnalisations côté client existantes vers SharePoint Framework. En outre, il indique un nombre d’éléments à prendre en compte lors de la planification de la migration.

Remarque

Les informations fournies dans cet article sont valables pour les personnalisations créées à l’aide des composants WebPart Éditeur de contenu et Éditeur de script. Lorsqu’il est fait référence au composant WebPart Éditeur de script, il s’agit des composants WebPart Éditeur de contenu et Éditeur de script.

Avantages de la migration de personnalisations côté client existantes vers SharePoint Framework

SharePoint Framework a été créé en tant que modèle de développement SharePoint axé sur le développement côté client. Bien que SharePoint Framework offre principalement des fonctionnalités d’extensibilité pour les sites d’équipe modernes, les personnalisations créées avec SharePoint Framework fonctionnent également avec l’expérience SharePoint classique. L’utilisation de SharePoint Framework pour créer vos personnalisations offre de nombreux avantages par rapport à l’utilisation de tout autre modèle de développement SharePoint disponible à ce jour.

Une seule opération de création, réutilisation sur l’ensemble des appareils

L’expérience utilisateur SharePoint moderne a été conçue pour prendre en charge en mode natif l’accès à des informations stockées dans SharePoint sur n’importe quel appareil. En outre, l’expérience moderne prend en charge l’application mobile SharePoint. Les solutions créées à l’aide de l’SharePoint Framework s’intègrent en toute transparence à l’expérience SharePoint moderne et peuvent être utilisées sur les différents appareils et à l’intérieur de l’application mobile SharePoint. Comme les solutions SharePoint Framework fonctionnent également avec l’expérience SharePoint classique, elles peuvent être utilisées par des organisations qui n’ont pas encore migré vers l’expérience moderne.

Plus robuste et plus durable

Dans le passé, les développeurs personnalisaient SharePoint en insérant des éléments DOM spécifiques dans l’interface utilisateur. Grâce à cette approche, ils pouvaient modifier l’expérience utilisateur standard ou proposer des fonctionnalités supplémentaires aux utilisateurs finals. Toutefois, ce type de solutions étaient susceptibles d’engendrer des erreurs. Le DOM de la page SharePoint n’ayant pas été conçu pour être une surface d’extensibilité, chaque modification qui y était apportée entraînait l’arrêt des solutions reposant sur celui-ci.

SharePoint Framework offre aux développeurs des api standardisées et des points d’extensibilité pour créer des solutions côté client et fournir aux utilisateurs finaux des fonctionnalités supplémentaires. Les développeurs peuvent utiliser SharePoint Framework afin de créer des solutions à l’aide d’une méthode prise en charge et durable. Ils n’ont plus à se soucier de l’incidence potentielle de futures modifications de l’interface utilisateur SharePoint sur leurs solutions.

Un accès simplifié aux informations dans SharePoint et Office 365

Microsoft développe continuellement les fonctionnalités de SharePoint et d’Office 365. À mesure que les organisations utilisent davantage les deux plateformes, il devient de plus en plus important pour les développeurs d’exploiter les informations et les insights stockés dans Office 365 pour créer des solutions riches. L’un des objectifs de SharePoint Framework est de faciliter la connexion à diverses API SharePoint et Office 365 pour les développeurs.

Des solutions adaptées aux besoins des utilisateurs

Les solutions côté client générées par l’incorporation de scripts n’offaient souvent pas aux utilisateurs finaux un moyen simple de les configurer en fonction de leurs besoins. La seule façon de les configurer consistait à modifier leur code ou à utiliser une interface utilisateur personnalisée conçue spécialement.

Les composants WebPart côté client de SharePoint Framework peuvent être configurés de façon standard à l’aide du volet de propriétés, que les utilisateurs ayant déjà travaillé avec des composants WebPart classiques connaissent déjà. Les développeurs créant des composants WebPart côté client peuvent choisir d’utiliser un volet de propriétés dynamique (par défaut) (chaque modification apportée à une propriété de composant WebPart est directement reflétée dans le corps du composant) ou un volet de propriétés non dynamique (les modifications apportées aux propriétés d’un composant WebPart doivent être appliquées explicitement).

Travail sur des sites sans script

Pour aider les organisations à gérer leurs personnalisations, Microsoft a publié la fonctionnalité Aucun script dans SharePoint Online. Lorsque l’indicateur Aucun script est activé pour le client ou pour une collection de sites spécifique, les personnalisations reposant sur l’ajout et l’incorporation de scripts sont désactivées.

Étant donné que SharePoint Framework composants WebPart côté client sont déployés via le catalogue d’applications avec une approbation préalable, ils sont autorisés à s’exécuter dans des sites sans script. Par défaut, le paramètre Aucun script est activé pour les sites d’équipe modernes et il est impossible d’y incorporer des scripts. Ainsi, l’utilisation de SharePoint Framework est le seul moyen pris en charge pour créer des personnalisations côté client dans des sites d’équipe modernes.

Similitudes entre les solutions SharePoint Framework et les personnalisations de composants WebPart Éditeur de script

Bien qu’elles reposent sur un nouveau modèle de développement à l’aide d’une nouvelle chaîne d’outils, les solutions SharePoint Framework sont similaires aux personnalisations du composant WebPart Éditeur de script que vous avez créées dans le passé. Comme elles s’appuient sur les mêmes concepts, vous pouvez plus facilement les migrer vers SharePoint Framework.

Exécution en tant qu’une partie de la page

Tout comme les personnalisations incorporées et les composants WebPart Éditeur de script, les solutions SharePoint Framework constituent une partie de la page. Ainsi, ces solutions ont accès au DOM de la page et peuvent communiquer avec d’autres composants sur la même page. En outre, cela permet aux développeurs d’adapter plus facilement leurs solutions aux différents facteurs de forme sur lesquels une page SharePoint peut être affichée, y compris l’application mobile SharePoint.

Contrairement aux compléments SharePoint, SharePoint Framework composants WebPart côté client ne sont pas isolés dans un iframe. Par conséquent, les autres éléments de la page peuvent également accéder à toutes les ressources auxquelles a accès le composant WebPart côté client spécifique. Il est important de garder cela à l’esprit lors de la création de solutions qui reposent sur un flux implicite OAuth avec des jetons d’accès de support, ou qui utilisent des cookies ou le stockage du navigateur pour stocker des informations sensibles. Étant donné que les composants WebPart côté client s’exécutent en tant que partie de la page, d’autres éléments de cette page peuvent également accéder à toutes ces ressources.

Utilisation de la bibliothèque de votre choix pour créer votre composant WebPart

Lorsque vous créez des personnalisations à l’aide du composant WebPart Éditeur de script, vous pouvez utiliser des bibliothèques telles que jQuery ou Knockout pour rendre votre personnalisation dynamique et plus réactive aux actions des utilisateurs. Lors de la création de composants WebPart côté client SharePoint Framework, vous pouvez utiliser n’importe quelle bibliothèque côté client pour enrichir votre solution, comme vous l’auriez fait auparavant. Un autre des avantages offerts par SharePoint Framework est la possibilité d’isoler votre script. Même si le composant WebPart est exécuté en tant que partie de la page, son script se présente sous forme de module, ce qui permet par exemple à différents composants WebPart sur la même page d’utiliser une version distincte de jQuery sans entrer en conflit les uns avec les autres. Cette fonction avancée vous permet de vous concentrer sur la valeur commerciale plutôt que sur des migrations techniques sans faire de compromis sur les fonctionnalités.

Exécution en tant qu’utilisateur actuel

Dans les personnalisations créées à l’aide du composant WebPart Éditeur de script, il vous suffisait d’appeler les API de SharePoint lorsque vous aviez besoin de communiquer avec ce dernier. La solution côté client s’exécutait dans le navigateur dans le contexte de l’utilisateur actuel et, en envoyant automatiquement le cookie d’authentification avec la demande, votre solution pouvait se connecter directement à SharePoint. Aucune autre authentification supplémentaire (comme lors de l’utilisation de compléments SharePoint) n’était nécessaire pour communiquer avec SharePoint. Le même mécanisme s’applique aux personnalisations créées sur SharePoint Framework, qui s’exécutent également sous le contexte de l’utilisateur actuellement authentifié et qui ne nécessitent pas non plus d’étapes d’authentification supplémentaires afin de communiquer avec SharePoint.

Utilisation du code côté client uniquement

Les solutions de composants WebPart SharePoint Framework et Éditeur de script s’exécutent dans le navigateur et peuvent contenir uniquement du code JavaScript côté client. Les solutions côté client présentent un certain nombre de limitations, telles que le fait de ne pas élever les autorisations dans SharePoint ou de contacter des API externes qui ne prennent pas en charge la communication cross-origin (CORS) ou l’authentification à l’aide d’un flux implicite OAuth. Dans ce cas, la solution côté client peut tirer parti d’une API côté serveur distante pour effectuer l’opération nécessaire et retourner les résultats au client.

Solution hôte dans SharePoint

La création de personnalisations SharePoint à l’aide de composants WebPart Éditeur de script permettait l’hébergement de leur code dans une bibliothèque de documents SharePoint standard. En comparaison avec les compléments SharePoint, cela nécessitait une infrastructure moins importante et permettait de simplifier l’hébergement de la solution. En outre, les organisations pouvaient se servir des autorisations SharePoint pour contrôler l’accès aux fichiers de la solution.

Bien que l’hébergement de solutions SharePoint Framework sur un CDN offre de nombreux avantages, cela n’est pas obligatoire et vous pouvez tout à fait choisir d’héberger leur code dans une bibliothèque de documents SharePoint standard. SharePoint Framework packages (fichiers *.sppkg) déployés dans le catalogue d’applications spécifient l’URL à laquelle SharePoint Framework pouvez trouver le code de la solution. Il n’existe aucune restriction concernant la nature de l’URL, tant que l’utilisateur qui parcourt la page comportant le composant WebPart peut télécharger le script à partir de l’emplacement spécifié.

Office 365 fournit la fonctionnalité de CDN public, qui vous permet de publier des fichiers à partir d’une bibliothèque de documents SharePoint spécifique vers un CDN. Le CDN public d’Office 365 offre le juste équilibre entre les avantages de l’utilisation d’un CDN et la simplicité d’hébergement de fichiers de code dans une bibliothèque de documents SharePoint. Si le fait que les fichiers de code soient disponibles publiquement n’est pas un problème pour votre organisation, l’utilisation du CDN public d’Office 365 est une option intéressante.

Différences entre les solutions SharePoint Framework et les personnalisations de composant WebPart Éditeur de script

Les personnalisations SharePoint générées à l’aide du composant WebPart SharePoint Framework et Éditeur de script sont similaires. Elles sont toutes exécutées en tant que partie de la page sous le contexte de l’utilisateur actuel et sont créées à l’aide de JavaScript côté client. Toutefois, elles présentent également des différences importantes qui peuvent influencer vos décisions architecturales et que vous devez garder à l’esprit lorsque vous concevez votre solution.

Exécution dans des sites sans script

Lorsque vous créiez des personnalisations côté client à l’aide du composant WebPart Éditeur de script, vous deviez prendre en compte le fait que le site sur lequel la personnalisation était utilisée comportait des scripts ou non. Si le site ne comportait aucun script, vous deviez demander à l’administrateur de désactiver le paramètre Aucun script ou créer votre solution différemment, en utilisant le modèle de complément par exemple.

Les solutions SharePoint Framework étant déployées par le biais du catalogue d’applications avec une approbation préalable, ils ne sont pas concernés par les restrictions concernant l’absence de script et ils fonctionnent sur tous les sites.

Déploiement et mise à jour par les services informatiques

Les composants WebPart Éditeur de script sont principalement utilisés par les développeurs non professionnels pour créer des personnalisations SharePoint. Avec de simples autorisations de propriétaire de site, les développeurs non professionnels parviennent à créer des personnalisations SharePoint convaincantes qui apportent une valeur commerciale. Chaque fois que la personnalisation doit être mise à jour, les utilisateurs disposant des autorisations nécessaires peuvent appliquer des mises à jour aux fichiers de script de la solution et les modifications sont immédiatement visibles par tous les utilisateurs.

Les solutions de composant WebPart Éditeur de script compliquent le suivi des personnalisations utilisées et de leur emplacement. En outre, les organisations ne savent pas quels scripts externes sont utilisés dans leur réseau intranet et ont accès à leurs données.

Grâce à SharePoint Framework, elles peuvent reprendre le contrôle. Étant donné que les solutions SharePoint Framework sont déployées et gérées de façon centrale dans le catalogue d’applications, les organisations ont la possibilité de les examiner avant de les déployer. De plus, toutes les mises à jour sont également déployées par le biais du catalogue d’applications, ce qui permet aux organisations de les vérifier et de les approuver avant de les déployer.

Pour une expérience utilisateur uniforme

Lorsqu’ils créaient des personnalisations à l’aide du composant WebPart Éditeur de script, les développeurs non professionnels étaient propriétaires de l’intégralité de leur DOM. Aucune recommandation n’existait concernant l’expérience utilisateur et le fonctionnement des personnalisations. Par conséquent, les différents développeurs ont créé des personnalisations à leur façon, entraînant un manque d’harmonisation de l’expérience utilisateur pour les utilisateurs finaux.

L’un des objectifs de SharePoint Framework est de normaliser la création des personnalisations côté client afin de les harmoniser du point de vue du déploiement, de la maintenance et de l’expérience utilisateur. Grâce à Office UI Fabric, les développeurs peuvent facilement donner à leurs solutions personnalisées l’apparence et le comportement d’un composant SharePoint, ce qui simplifie leur adoption par les utilisateurs. La chaîne d’outils SharePoint Framework génère des fichiers de package pour les solutions, qui sont déployés vers le catalogue d’applications, ainsi que des ensembles de scripts, qui sont déployés vers l’emplacement d’hébergement de votre choix. Chaque solution est structurée et gérée de la même façon.

Ne pas modifier le DOM en dehors de la personnalisation

Les composants WebPart Éditeur de script étaient souvent utilisés pour modifier des parties de la page (par exemple, pour ajouter des boutons à la barre d’outils, ou modifier le titre ou la personnalisation de la page). Ces personnalisations s’appuyaient sur l’existence d’éléments DOM spécifiques ; ainsi, lorsque l’interface utilisateur SharePoint était mise à jour, la personnalisation était susceptible d’être interrompue.

SharePoint Framework mise sur l’utilisation d’une approche plus structurée et plus fiable pour personnaliser SharePoint. Au lieu d’utiliser des éléments DOM spécifiques pour personnaliser SharePoint, SharePoint Framework fournit aux développeurs une API publique qu’ils peuvent utiliser pour étendre SharePoint. Le composant WebPart côté client est la seule forme prise en charge par SharePoint Framework, mais nous travaillons à la future prise en charge d’autres formes, comme les équivalents de JSLink et des actions utilisateur personnalisées, afin que les développeurs puissent implémenter les scénarios de personnalisation les plus courants à l’aide de SharePoint Framework.

Distribution sous forme de packages

Les personnalisations côté client SharePoint utilisaient souvent des listes et des bibliothèques SharePoint pour stocker leurs données. Lors de la génération à l’aide du composant WebPart Éditeur de script, il n’y avait aucun moyen simple de provisionner automatiquement les prérequis nécessaires. Pour déployer une personnalisation identique vers un autre site, il fallait souvent copier le composant WebPart, mais également recréer correctement et maintenir le stockage de données nécessaire.

SharePoint Framework solutions sont distribuées sous forme de packages pouvant provisionner automatiquement leurs prérequis, tels que des champs, des types de contenu ou des listes. Les développeurs qui créent le package peuvent indiquer les artefacts requis par la solution. Lorsque le package est installé dans un site, les artefacts spécifiés sont créés. Cela simplifie considérablement le processus de déploiement et de gestion de la solution sur plusieurs sites.

Utilisation de TypeScript pour créer des solutions plus robustes et plus faciles à tenir à jour

Lorsqu’ils créaient des personnalisations à l’aide du composant WebPart Éditeur de script, les développeurs non professionnels utilisaient souvent le langage JavaScript brut. Souvent, ces solutions ne comportaient aucun test automatisé et la refactorisation du code pouvait engendrer des erreurs.

SharePoint Framework permet aux développeurs de profiter du système de type TypeScript lors de la création de solutions. Grâce au système de type, les erreurs sont détectées pendant le développement, et non pendant l’exécution. De plus, le processus de refactorisation du code est désormais plus simple, car les modifications apportées au code sont protégées par TypeScript. Comme l’ensemble du langage JavaScript constitue un langage TypeScript valide, la barrière à l’entrée est faible et vous pouvez migrer petit à petit votre langage JavaScript vers TypeScript, en augmentant la maintenabilité de votre solution.

Manque de fiabilité de l’objet spPageContextInfo

Auparavant, lorsque les développeurs créaient des personnalisations côté client réutilisables, ils utilisaient l’objet JavaScript spPageContextInfo pour obtenir des informations sur la page, le site ou l’utilisateur en cours. Grâce à cet objet, ils pouvaient facilement rendre leur solution réutilisable sur les différents sites dans SharePoint et ne pas avoir à utiliser d’URL fixes.

L’objetspPageContextInfo est toujours présent sur les pages SharePoint classiques ; toutefois, il ne peut pas être utilisé de façon fiable avec des bibliothèques et des pages SharePoint modernes. Lors de la création de solutions sur SharePoint Framework, il est plutôt conseillé aux développeurs d’utiliser l’objet [IWebPartContext.pageContext](/javascript/api/sp-webpart-base/iwebpartcontext), qui contient des informations sur le contexte concernant la solution spécifique.

Aucun accès par défaut au modèle objet JavaScript SharePoint

Lorsqu’ils créaient des personnalisations côté client pour l’expérience utilisateur SharePoint classique, de nombreux développeurs utilisaient le modèle objet JavaScript (JSOM) pour communiquer avec SharePoint. Grâce à JSOM, ils disposaient d’IntelliSense et d’un accès facile à l’API SharePoint de façon semblable au modèle objet côté client (CSOM). Dans les pages SharePoint classiques, la partie principale du JSOM était présente par défaut sur la page, et les développeurs pouvaient charger d’autres parties pour communiquer avec la recherche SharePoint, par exemple.

L’expérience utilisateur SharePoint moderne n’inclut pas le JSOM SharePoint par défaut. Les développeurs peuvent tout de même le charger, mais il est recommandé d’utiliser l’API REST à la place. L’utilisation de REST a un caractère plus universel et interchangeable entre les différentes bibliothèques côté client, telles que jQuery, Angular ou React.

Microsoft ne va plus travailler activement sur le JSOM. Si vous préférez utiliser une API, vous pouvez utiliser à la place la Bibliothèque principale JavaScript de pratiques et de modèles SharePoint, qui vous fournit une API Fluent et des typages TypeScript.

Migration de personnalisations existantes vers SharePoint Framework

La migration de personnalisations de composant WebPart Éditeur de script vers SharePoint Framework présente de nombreux avantages pour les utilisateurs finals et les développeurs. Lorsque vous envisagez de migrer des personnalisations existantes vers le SharePoint Framework, vous pouvez choisir de réutiliser autant de scripts existants que possible ou de réécrire complètement la personnalisation.

Réutilisation de scripts existants

Lors de la migration de personnalisations existantes de composant WebPart Éditeur de script vers SharePoint Framework, vous pouvez choisir de réutiliser vos scripts existants. Bien que SharePoint Framework encourage l’utilisation de TypeScript, vous pouvez utiliser le langage JavaScript brut et le transformer petit à petit en langage TypeScript. Cette approche peut vous convenir si vous devez prendre en charge une solution spécifique pendant une durée limitée ou si vous disposez d’un budget limité.

Il n’est pas toujours possible de réutiliser des scripts existants dans une solution SharePoint Framework. Par exemple, les solutions SharePoint Framework sont présentées sous forme de modules JavaScript et chargées de façon asynchrone sur une page. Certaines bibliothèques JavaScript ne fonctionnent pas correctement lorsqu’elles sont référencées dans un module ou qu’elles doivent être référencées d’une façon spécifique. De plus, le fait de s’appuyer sur des événements de page comme onload() ou d’utiliser la fonction ready() jQuery peut entraîner des résultats insatisfaisants.

Étant donné la variété des bibliothèques JavaScript, il n’existe aucun moyen simple de savoir à l’avance si vos scripts existants peuvent être réutilisés dans une solution SharePoint Framework ou si vous devez les réécrire après tout. La seule façon de le savoir consiste à essayer de déplacer les différentes parties vers une solution SharePoint Framework et de voir si elles fonctionnent comme prévu.

Réécriture de la personnalisation

Si vous avez besoin de prendre en charge votre solution plus longtemps, si vous souhaitez mieux utiliser les SharePoint Framework ou s’il s’avère que vos scripts existants ne peuvent pas être réutilisés avec le SharePoint Framework, vous devrez peut-être réécrire complètement votre personnalisation. Bien que cette solution soit plus onéreuse que de réutiliser les scripts existants, elle donne de meilleurs résultats dans le temps : une solution qui fonctionne mieux, qui est plus facile à tenir à jour et à utiliser.

Lorsque vous réécrivez une personnalisation de composant WebPart Éditeur de script vers une solution SharePoint Framework, vous devez commencer en gardant à l’esprit les fonctionnalités que vous souhaitez obtenir. Pour implémenter l’expérience utilisateur, vous devez envisager d’utiliser Office UI Fabric afin que votre solution semble faire partie intégrante de SharePoint. Pour les composants spécifiques, tels que les graphiques ou les curseurs, recherchez des bibliothèques modernes qui sont distribuées sous forme de modules et qui comportent des typages TypeScript. Vous pouvez ainsi intégrer plus facilement le composant dans votre solution.

Aucun composant ne peut être considéré meilleur qu’un autre pour un scénario donné. SharePoint Framework offre une flexibilité qui permet de s’adapter aux scénarios les plus populaires. Vous pouvez ainsi transformer vos personnalisations côté client existantes en solutions SharePoint Framework riches en fonctionnalités.

Conseils de migration

Lors de la transformation de personnalisations existantes de composant WebPart Éditeur de script en personnalisations SharePoint Framework, il existe quelques modèles communs.

Déplacement de code existant vers SharePoint Framework

Les personnalisations SharePoint créées à l’aide du composant WebPart Éditeur de script se composent souvent des balises HTML, compris dans le composant WebPart, et d’une référence ou plus à des fichiers JavaScript. Lors de la transformation de votre personnalisation existante vers une solution SharePoint Framework, les balises HTML du composant WebPart Éditeur de script devront probablement être déplacées vers la méthode render() du composant WebPart côté client SharePoint Framework. Les références à des scripts externes seront changées en références dans la propriétéexternals dans le fichier./config/config.json. Les scripts internes seront copiés vers le dossier source du composant WebPart et référencés à partir de la classe de composant WebPart à l’aide des instructions require().

Référencement de fonctions à partir de fichiers de script

Pour que vous puissiez référencer des fonctions à partir de fichiers de script, celles-ci doivent être définies en tant qu’export. Imaginez un fichier JavaScript existant que vous souhaiteriez utiliser dans un composant WebPart côté client SharePoint Framework :

var greeting = function() {
  alert('How are you doing?');
  return false;
}

Pour appeler la fonctiongreeting à partir de la classe de composant WebPart, il vous faudrait modifier le fichier JavaScript comme suit :

var greeting = function() {
  alert('How are you doing?');
  return false;
}

module.exports = {
  greeting: greeting
};

Ensuite, vous pouvez référencer le script dans la classe de composant WebPart et appeler la fonction greeting comme suit :

public render(): void {
  this.domElement.innerHTML = `<input type="button" value="Click me"/>`;

  const myScript = <any> require('./my-script.js');
  this.domElement.querySelector('input').addEventListener('click', myScript.greeting);
}

Exécution d’appels AJAX

De nombreuses personnalisations côté client utilisent jQuery pour exécuter des demandes AJAX en raison de sa simplicité et de la compatibilité entre navigateurs. Si vous utilisez jQuery uniquement pour ces raisons, vous pouvez exécuter les appels AJAX à l’aide du client HTTP standard fourni avec SharePoint Framework.

SharePoint Framework fournit deux types de client HTTP : SPHttpClient, conçu pour exécuter des demandes envoyées à l’API REST SharePoint, et HttpClient, conçu pour émettre des requêtes web vers toutes les autres API REST. Voici un exemple d’exécution d’un appel à l’aide de SPHttpClient pour obtenir le titre du site SharePoint actuel :

this.context.spHttpClient.get(`${this.context.pageContext.web.absoluteUrl}/_api/web?$select=Title`,
SPHttpClient.configurations.v1,
{
  headers: {
    'Accept': 'application/json;odata=nometadata',
    'odata-version': ''
  }
})
.then((response: SPHttpClientResponse): Promise<{Title: string}> => {
  return response.json();
})
.then((web: {Title: string}): void => {
  // web.Title
}, (error: any): void => {
  // error
});

Voir aussi