Ignite Live Blog: Session THR2227 – Surfacing SPFx Solutions in SharePoint and Teams

This post has been republished via RSS; it originally appeared at: Microsoft Teams Events Blog articles.

Build once, run everywhere

Microsoft has presented a clear and consistent message in its developer-focused sessions at Microsoft Ignite: developers who build solutions for the Office 365 ecosystem will soon be able to build one solution and deploy it to a common runtime that spans multiple Office 365 apps, beginning with SharePoint and Teams and ultimately adding support for all of Office.

This provides distinct advantages for 3 key Office 365 consumers:

• For End Users, apps and information are available everywhere they work, regardless of the tool
• For IT Admins, managing deployment and distribution of custom applications is streamlined and simplified
• For Developers, one solution can reach multiple workloads (for example, SharePoint and Teams) and developers can apply a single set of development concepts and experiences to build apps across the entire Office 365 ecosystem

In practice

A simple example (demoed in this session and available in GitHub here) might cover the following scenario:

1. A developer builds an application as a SharePoint Framework web part, harnessing the Microsoft Graph to add new events to the end user's Outlook (Exchange) calendar
2. The developer targets both SharePoint and Microsoft Teams by configuring the manifests.json file
3. On build, the Yeoman generator builds and deploys (1) a SharePoint Framework web part that users can add to SharePoint pages, and (2) a Microsoft Teams App Package that users can add as tabs to channels in Microsoft Teams
4. At configuration time (when the end user adds the web part to a SharePoint page or adds the Teams app as a tab to a channel), the configuration screen for the Teams tab mimics that of the configuration panel for the SharePoint web part-- because it's the same code!
5. At runtime, the app can determine its context-- for example, retrieve information about the site and page in which the SharePoint Framework web part is running, or the channel to which the Microsoft Teams app has been added-- and provide an adaptive user experience based on that context.

TL;DR: Build once, deploy and run everywhere.

A quick look at the relevant code

I won't dive into the ins and outs of all of Wictor's code here (feel free to check out the Readme.md in his repo), but there are a few important pieces to pull out:

Packaging the SPFx web part for Teams

First, Wictor built a SharePoint Framework web part using the SPFx Yeoman generator (source is in the spfx folder).  Next, Wictor generated a Teams app with the Teams Yeoman generator (source is in the teams folder).

Next, he updated the manifest.json file in the /teams/src/manifest/ folder to include the unique Id and path of the SPFx web part (note that the URL will change when this capability goes GA):

 "configurableTabs": [
        {
            "configurationUrl": "https://spoppe-a.akamaihd.net/files/sp-client-master_20180727.004/sp-teams-tab/sp-teams-tab.html?dest=/_layouts/15/webpart.aspx?openPropertyPane=true&teams&componentId=374bc334-0a1f-4cbc-82a6-4d87f71e6976",
            "canUpdateConfiguration": true,
            "scopes": [
              "team"
            ] 
        }
    ],

Wictor was then able to build and deploy the same app as:

1. A web part in SharePoint, and
2. An app in Teams. 

Reacting to the app context at runtime

In the main app code, Wictor wrote a quick method to check if the user context was in Microsoft Teams:

private isInTeams(): boolean {
    return (<any>this.context.pageContext).teams !== undefined;
  }

He then used this throughout the app code, performing some different actions at runtime if a Teams context was detected:

if (this.isInTeams()) {
                    // if we're in Teams we already know the channel
                    channel = (<any>this.context.pageContext).teams.channelId;
                  } else {
                    // If we're not in Teams then use the channel submitted in the action
                    channel = (<any>submitAction.data).channel;
                  }

Takeaways

This is the first step in a very important journey for developers on the Office 365 ecosystem, including SharePoint and Teams but eventually extending to the rest of Office.

With cross-pollination between SharePoint and Teams developer toolchains, developers can create great user experiences built on the Microsoft Graph and deploy them as SharePoint SPFx web parts and Microsoft Teams apps (tabs) from a single codebase.  And these applications are context-aware, providing developers even more opportunities to delight end users by incorporating unique app context into the user experience.

Resources & next steps

• View session details on the Ignite portal: Session details
• Check out the source code for Wictor's demo: Sample code on GitHub
• Watch the SharePoint Framework GitHub page for v1.7 release, which will include the functionality in Wictor's code
• Take a look at the SharePoint Framework public roadmap, which outlines features you can expect to find in upcoming releases