Microsoft’s SharePoint collaboration platform isn’t new, but its latest evolution is taking it to new places and to new users. Part of that change is a new way of building applications, one that’s taking SharePoint development to Microsoft’s Teams chat-based collaboration environment and even into mixed reality with HoloLens.
SharePoint apps aren’t complex; they’re generally front-ends to line-of-business tools, implementing a piece of workflow. Running inside SharePoint web pages, they’re a click away from your work and can be built into common workflows, adding web parts to existing content. With Teams now a key part of Microsoft’s collaboration strategy, beginning its rollout out to enterprise Office 365 accounts, it’s perhaps time to consider blending the two technologies using Teams’ upcoming support for the SharePoint Framework (SPFx) development environment.
You still get the option of using iFrames to host web parts, but now as a security tool: by hosting an SPFx web part in an iFrame you’re now isolating it from the rest of your application, giving it different permissions from the rest of an app.
SEE: Microsoft SharePoint: A guide for business professionals (Tech Pro Research)
Recent releases of SPFx (from 1.7 onward) don’t only support SharePoint; their web parts will render inside Microsoft Teams, running as apps in Teams tabs. It’s a useful option, as your existing SharePoint apps can quickly become Teams apps. Users won’t need to log into SharePoint to see and use them; they’ll be available alongside regular team conversations and collaboration, installed from the Teams App Catalog.
While it’s currently in preview, the process is easy enough that you can start building new apps, or converting existing SPFx code, ready for release. If you need to test your code, Microsoft lets you sideload apps into Teams.
The most important question isn’t how you’re going to build your app, it’s how you’re going into link it into the way your users work. Initially SPFx apps will render as separate tabs in Teams, so users will need to explicitly install them in their client and switch to and from them when they need to access information or complete tasks. Much of Teams’ application platform is focused on dealing with ‘micro-tasks’ — quick approvals or queries that can be done alongside other tasks. It’s a good philosophy to use when building your SPFx apps, drilling down into simple actions that only require a quick in-and-out from a user.
Building SPFx code for Teams
Building a new app isn’t hard. Most of the tools you need load using familiar web development tooling like npm and Yeoman. You’ll start by installing a default web part in a local directory, using your usual editor to work with the resulting files. By default you’ll now find a Teams folder in every new web part you create, making it a lot easier to edit and create new tabs.
Initially you’ll use Yeoman to set up your development environment. It’s a command-line tool, but you can run it from inside Visual Studio Code using its built-in terminal. Yeoman constructs the scaffolding for your app, using a simple set of questions and answers from its SharePoint Generator. After stepping through the Yeoman script, and when it’s got all the information it needs, it will create the directory structure for a SPFx web part and download and install any necessary dependencies.
Much of what you need to handle running a SPFx app in Teams is handled by the manifest.json file in the Teams directory. You’ll find it alongside sample icons that you’ll need to update for your app. Update it with the details of your app and its icons.
When you’re ready to edit your web part code you’ll first need to ensure that it can work inside a Teams tab, by adding a variable to hold the Teams context. This will be initialised when you start the app, checking whether it’s running in Teams or not. You’ll use it to show content that’s only rendered in Teams, and to ensure that SharePoint-specific features aren’t available to Teams users. Using it as a context switch allows you to have one set of SPFx code that can handle both Teams and SharePoint deployments, keeping application maintenance to a minimum.
Code running inside SPFx web parts is written using your choice of web framework and components, and once it’s ready you can package it up and deliver it to a Teams app catalogue. Microsoft’s SPFx tooling uses gulp to build your code and bundle it up for distribution. As soon as it’s packaged, it’s ready for upload. Initially you can add it to your SharePoint apps folder, either in an on-premises SharePoint install or via Office 365. You’ll then need to set your app’s trust settings, before making it available to your Teams users.
Integrating SPFx and Teams with your line-of-business apps
SPFx goes further than integrating your Teams applications with SharePoint, building on the growing Microsoft Graph APIs to integrate with Office 365 and Microsoft 365. Like older SharePoint development technologies, you can use web parts from Microsoft, third parties, a growing set of open-source community components, or custom components developed by your own SharePoint development team.
SEE: Windows 10 power tips: Secret shortcuts to your favorite settings (Tech Pro Research)
Using SPFx 1.7 you can now also use web parts to handle data connections, so you can extract information from a page and send it back to a server, and link different web parts in the same page. Teams apps can use them to build complex views, for example mixing a picker and a view control in the same page. It’s easy to imagine a tool for developers that uses this approach to list Azure DevOps pull requests for a project, with a view that shows both code and comments.
The relationship between Teams and SharePoint goes both ways, as you can also host Teams Tabs in SharePoint. Microsoft seems to finally understand that individuals have very different approaches to collaboration, and so its tools need to offer access to the same applications through users’ preferred channels, whether that’s in a browser or in a conversation.