Contents tagged with SharePoint Framework

  • SharePoint Framework has now reached General Availability - such a great journey

    Tags: SharePoint Framework, Office 365, SharePoint

    Let me start with congratulating the SharePoint Framework team on an amazing job and an amazing journey reaching this GA milestone.

    The SharePoint Framework plays a significant part of the SharePoint future, yes - this is only the first version with a lot of new features on the way, and it is a part of the new SharePoint wave. I've haven't seen this interest in SharePoint for many years and I'm glad I'm still in this business. Delivering top notch collaboration solutions for our clients at Avanade. The SharePoint Framework will make it easier for us to customize SharePoint and it will also bring a lot more value for our clients in the end allowing them to stay evergreen and not being tied into "workarounds" and pesky SharePoint Designer hacks or arbitrary JavaScript snippets.

    I'm extremely glad that I've been a part of this journey, seeing the team making the awesome stuff they've done. For me it started back in the fall of 2015 when we we're shown some very early ideas on where to go next and also some whiteboard sessions where we had an open and frank discussion about what the requirements were from the field. This openness is something that I think has made the difference this time and made the SharePoint Framework into what it is. All discussions was kept very secret and I'll tell you it was hard not to cry out to everyone how excited I was on the progress.

    Early 2016 I was part of the first DevKitchen, where we had the opportunity to use SharePoint Framework for the first time. The team had only in a couple of months created something that actually worked! It was very satisfying to build that first web part (I do think that I was the first outside of Microsoft that actually built a client-side Web Part!).  The framework had its quirks and issues back then, but they kept the speed up and delivered. A few more DevKitchens were hosted and finally in May they revealed the SharePoint Framework to the public.

    Just after the summer everyone could get their hands on the first public release of the SharePoint Framework and the SPFx Team opened the floodgates of feedback through their Github repository. It has been fantastic to see all the support, wishes, bugfixes, samples and documentation that the public (and specifically Waldek) has produced to support the SharePoint Framework. And how fast and agile the team has responded to all the requests and issues. This is how Microsoft should build more stuff!

    I've tried to do my best giving feedback as a consultant, developer and things my clients need. I'm particular proud of the enterprise guidance documentation that I've helped with. I absolutely love being part of this community.

    Now, we're here, within a few weeks all tenants in Office 365 should be able to use the SharePoint Framework to build great stuff and awesome client-side Web Parts. We're already in the midst of porting our solutions to take advantage of the SharePoint Framework and getting it in the hands of our clients.

    Thank you to the SharePoint Framework Team - I'm so looking forward to what's happening next. See you in a few weeks in Redmond ;-).

    Let's make SharePoint great again!

  • SharePoint Framework: how to properly dynamically populate dropdown property pane fields

    Tags: SharePoint Framework

    One of the key parts of SharePoint Web Parts is the ability to have them configurable using the Web Part properties. This story is still true with client-side Web Parts in the new SharePoint Framework. In this post I will show you one of the more common scenarios; how to populate drop downs (and other fields) in the property pane dynamically. But also show you how what's wrong with the current implementation.

    Client-side Web Part Property Pane basics

    The Property Pane in client-side Web Parts are defined by the propertyPaneSettings method. It's a method that returns an IPropertyPaneSettings object representing the pages, groups and fields. This method is invoked whenever you click to edit the Web Part. The method is "synchronous" meaning that you should return a static set of pages, groups and fields - there's no option to wait for it to load (SPFx issue #127).

    Defining the Dropdown

    For a Dropdown we use the PropertyPaneDropdown field and specify for instance it like this, in the propertyPaneSettings method.

    PropertyPaneDropdown('listName', {
      label: strings.DescriptionFieldLabel,
      options: this._options
    })

    In this case the options property references a local variable defined as below:

    private _options: IPropertyPaneDropdownOption[];

    Loading the data…

    But when do we load this data into the local variable. We do have a couple of options to do this, but there really is only one viable option at the moment and that is to use the onInit<T>() method. This method always runs when the Web Part is loaded or is added to a page, and it only runs once and it is the only option we have if we want to load something using a promise and make sure to have it loaded before we have the chance of rendering the property pane. The onInit method returns a Promise and that allows us to actually block the loading of the Web Part until we have the data.

    To load data, mock or live, I've created a simple list data provider, that you can find in the following Gist. Pay attention to the fact that I have set a delay on the mock loading to 5 seconds, this is to simulate a slow request and show you how bad this current implementation actually is. https://gist.github.com/wictorwilen/0bf866ee4fda2f9611f43ee17b9127d5

    Then I implement the onInit method as follows:

    public onInit<T>(): Promise<T> {
      let dataService = (this.context.environment.type === EnvironmentType.Test || this.context.environment.type === EnvironmentType.Local) ?
        new MockListsService() :
        new ListsService(this.context);
    
      this._options = [];
    
      return new Promise<T>((resolve: (args: T) => void, reject: (error: Error) => void) => {
        dataService.getListNames().then(lists => lists.forEach(list => {
          this._options.push(<IPropertyPaneDropdownOption>{
            text: list,
            key: list
          });
          resolve(undefined);
        }))
      });

    First of all I create my data service object (mock or real one). Then I create a new Promise that uses my list service and once the list data is read it populates the local variable holding the data for our dropdown and finally I resolve the promise.

    There are some articles and Github repos that uses another approach, they just return a resolved promise and let the call to the external data service run in the background. If that background request takes to long time (the simulated 5 seconds for instance) or fails then the user might have time to open the property pane and see an empty dropdown.

    Now when the web part is added to a page or a page a loaded with that web part the onInit method will "block" the web part from rendering until it has the data for the property pane. Well, that's not good, but that's how it is at the moment. There is however a possibility that we might be able to use displayMode property of the web part and only do this when we are in edit mode. I have not been able to verify this as the workbench always are in edit mode and none of my tenants actually loads the client side web parts in the modern pages - I'll get back on this.

    Another annoying thing is that since this is blocking the rendering, not even showing a spinning wheel or something, the user experience is quite bad if you have long running calls since nothing is shown (SPFx issue #228).

    Summary

    I've now shown you how to pre-load data for your property pane fields, yes same approach works for other field types than dropdowns as well. But is this the proper way then? Nope, it isn't but I have great hopes that this will be fixed in a better manner (see linked issues). If not we still have the option of creating completely custom property pane fields that allows us to do basically whatever we want.

  • SharePoint Framework Nuggets: working with GUIDs

    Tags: SharePoint Framework

    SharePoint developers - we do like GUIDs, don't we. We all read RFC4122 both once and twice. And now with SharePoint Framework and the goal to embrace all them Macintosh and open source people - they gotta have their fair share of GUIDs.

    And to aid with that the SharePoint Framework got some really nice GUID features, although a bit unpolished as you might notice - but this is all preview bits at the time of writing.

    SharePoint Framework Nuggets - GUIDs

    The Guid class

    First of all we must have the option to create GUIDs. There might be a situation that you need to store something really, really unique - to help with the we do have the Guid class in the @microsoft/client-sp-base module. This class both allows you to create new Guids, parse Guids and validate Guids.

    This is how you import the Guid class:

    import { Guid } from '@microsoft/sp-client-base';

    Then to create a Guid, you use the code below. The newGuid method can take an optional parameter if you need to create a custom random generator. By default it generates a version 4 UUID, also known as a pseudo random UUID, which can be generated in a browser. I suggest you skip passing in custom random generators.

    var guid: Guid = Guid.newGuid();

    What if someone gives a "GUID" to you, can you trust it is a proper Guid, no you can't you need to validate it. That can be done using the isValid method, which takes a string as in input.

    if( Guid.isValid(' f0a1f189-dae4-49f5-8846-3a17429fd52') ) { alert('Valid') };

    Then we finally also have a method to parse a string potentially containing a Guid, tryParse. The method will either return a Guid object or undefined.

    var guid: Guid = Guid.tryParse('f0a1f189-dae4-49f5-8846-3a17429fd52');

    The GuidHelpers class (@internal)

    [Update 2016-09-20] - The GuidHelpers class is marked internal and will be removed in future builds of the SharePoint Framework.

    There's also another class in SharePoint Framework for Guids, the GuidHelpers class. This class lives in the @microsoft/sp-client-preview module. It has a set of similar function to generate and validate Guids, but it does not work with Guid objects, it uses strings instead. For instance the GuidHelpers.generateGuid() returns a string. Another issue is that the GuidHelpers.isValid() does not validate Guids the same way as the Guid.isValid does (issue #201 in the SPFx Repo).

    GUID validation issues

    At the moment (drop 3 of SPFx) I would stay away from the GuidHelpers class.

    As usual there's some code samples of this to be found in this Github repo: https://github.com/wictorwilen/spfx-nuggets

    Happy GUIDing!

  • SharePoint Framework Nuggets: logging like a pro

    Tags: SharePoint Framework, SharePoint

    I guess that almost every application or solution you ever built has contained some portions of a logging mechanism. And how many of you have written your own - yup, all of you! But what about the SharePoint Framework - yes, it has built-in logging!

    SharePoint Framework Nuggets - logging like a pro

    How to log in the SharePoint Framework

    Logging is a very convenient and easy way to keep track of events happening, instead of having breakpoints, or in JavaScript even worse - alerts. The SharePoint Framework (SPFx) has as all decent frameworks a built-in logging mechanism, albeit very simple, but still yet valuable. It's contained in the @microsoft/sp-client-base module and the class is called Log. To use it in your SharePoint Framework solutions you need to import it as follows:

    import {
      Log
    } from '@microsoft/sp-client-base';

    The Log class contains four static methods for logging:

    • info
    • warn
    • error
    • verbose

    The names are exactly what you expect, the info is used for information, warn for warnings, error for errors and verbose for when you just have to much on your mind and want to spit it out.

    In the SharePoint Framework implementation all logging is done to the JavaScript console and you can see the logging using the developer tools of your favorite browser. It can take some searching to find them as SPFx spits out quite a lot of logging by itself.

    All static methods have the same signature, except the error method - they take three arguments:

    • source: the source of the logging information (max 20 characters), such as method or class name
    • message: the actual message to log (max 100 characters)
    • scope: an optional service scope (more on this one later)

    The error method takes an Error object instead of the message string, otherwise they are the same.

    This is how it could be used in client side web part:

    public render(): void {
      this.context.statusRenderer.clearError(this.domElement);
      this.context.statusRenderer.displayLoadingIndicator(this.domElement, strings.Loading);
      Log.verbose('SpFxNuggets', 'Invoking render');
    
      this._webInfoProvider.getWebInfo().then((webInfo: IWebInfo) => {
        if (this.properties.fail) {
          throw new Error('Mayday');
        }
        Log.info('SpFxNuggets', 'Service OK', this.context.serviceScope);
        this.context.statusRenderer.clearLoadingIndicator(this.domElement);
        this.context.domElement.innerHTML = `<h1>${webInfo.title}</h1>`;
    
      }).catch((err) => {
        Log.error('SpFxNuggets', err);
        this.context.statusRenderer.clearLoadingIndicator(this.domElement);
        this.context.statusRenderer.renderError(this.domElement, err);
      });
    }
    

    In the example above I use the verbose method to log that we're in the render method. Just verbose information. I also added logging to when the service returns (the promise is fulfilled) to log information that it has returned. In that info method I use the service scope of the web part, and when using the service scope, it replaces my source with the real name (JavaScript name) of the web part. Finally I log the error in the catch method. The image below shows the console output.

    Console output

    As usual you can find all the source code in this repository: https://github.com/wictorwilen/spfx-nuggets

    Happy logging!

  • SharePoint Framework Nuggets: render error messages

    Tags: SharePoint Framework, SharePoint

    Do you write code that potentially can throw an error or an exception? Oh, you don't - but sure you use a web service or external service or something that can throw an error. Well, it is you responsibility to handle the error and make sure to inform the user in a good way that something bad happened. With that I mean, do not show just a Guid.

    With the SharePoint Framework being all client side I think it is important to have control of your client side Web Parts and make sure that you properly handle and display error messages in a consistent way. In this short post I will not go in to the JavaScript error handling details, but rather show you another nugget in the SharePoint Framework that helps you render error messages in a standardized and consistent way.

    SharePoint Framework Nuggets - Render error messages

    Render Error messages

    Just as in the last post on the loading indicator the SharePoint Framework actually has built-in functions for rendering messages in SharePointy way. In the same class (and interface) as we had the loading indicator functions we also have two methods for managing error messages, found in the context of the current client side Web Part.

    • renderError(domElement: HTMLElement, error: Error | string): void;
    • clearError(domElement: HTMLElement): void;

    The renderError  method is used to display an error message in an HTML element. It has one parameter for the error message, which can either be a string or an Error object. And the clearError removes any rendered errors in the specified DOM element.

    Here's an example on how we could use it:

    public render(): void {
      this.context.statusRenderer.clearError(this.domElement);
      this.context.statusRenderer.displayLoadingIndicator(this.domElement, strings.Loading);
    
      this._webInfoProvider.getWebInfo().then((webInfo: IWebInfo) => {
        if(this.properties.fail) {
          throw new Error('Mayday');
        }
        this.context.statusRenderer.clearLoadingIndicator(this.domElement);
        this.context.domElement.innerHTML = `<h1>${webInfo.title}</h1>`;
    
      }).catch( (err) => {
        this.context.statusRenderer.clearLoadingIndicator(this.domElement);
        this.context.statusRenderer.renderError(this.domElement, err);
      });
    }
    

    It's the same render method that was in the loading indicator demo but with the difference that we have added the clearError method at the beginning of the render method (once again a redundant operation since the displayLoadingIndicator will override anything inside the DOM element, but you get the point). Then I introduced a property on the Web Part that when set it will throw an error and in our catch method we use the renderError method to render the error, as shown below.

    SPFxNuggets-error

    Fully working code can be found at this repo: https://github.com/wictorwilen/spfx-nuggets

    If you carefully explored the latest drops of the SharePoint Framework (yes, this is all still beta and bits and pieces are moving around) you might notice that the BaseClientSideWebPart contains direct access to these methods (clearError and renderError). The clearError is just calling out to the statusRenderer while the renderError method first clears the loading indicator, as I do manually above, then renders the error and finally also logs the error.

    Good luck!

  • SharePoint Framework nuggets: the loading indicator

    Tags: SharePoint Framework, SharePoint

    SharePoint Framework is all about rendering stuff on the client side, avoiding the long overdue ASP.NET Web Forms technology that SharePoint (Online) is still fundamentally based on. When rendering things client side everything is done asynchronously, to avoid locking down the UI threads and having a user experience that is fluent.

    In order to give the user good feedback that things are happening in the background, you need to have some kind of visual cue that tells the user - hey I'm doing stuff now, gimme a minute. There are thousands of different ways to do this and everyone does it differently; ranging from animated gifs to "loading" texts. And everyone using different methods does not always help with the user experience - so why don't we have a common way to do this?

    We actually do have this built into the SharePoint Framework!

    SharePoint Framework Nuggets - The Loading Indicator

    The SharePoint Framework Loading Indicator

    The SharePoint Framework contains a set of nifty methods that we can use to show a loading indicator in standardized and common way.

    The SharePoint Framework contains a special interface and corresponding implementation that is called IClientSideWebPartStatusRenderer. This interface defines two methods:

    • displayLoadingIndicator(domElement: Element, loadingMessage: string): void;
    • clearLoadingIndicator(domElement: Element): void;

    The first one, displayLoadingIndicator, is used to create a loading indicator with a spinning wheel and a loading text and then replace the inner contents of a HTML element with that code. For instance, for client-side Web Parts that is loading data dynamically should use this as one of the first things in the render() method. The second one, clearLoadingIndicator, does the opposite, it removes the loading indicator.

    The IClientSideWebPartStatusRenderer is always accessible through the IWebPartContext, that is on the context object of your Web Part.

    Here's an example on how to use it:

    public render(): void {
      this.context.statusRenderer.displayLoadingIndicator(this.domElement, strings.Loading);
    
      this._webInfoProvider.getWebInfo().then((webInfo: IWebInfo) => {
        this.context.statusRenderer.clearLoadingIndicator(this.domElement);
        this.context.domElement.innerHTML = `<h1>${webInfo.title}</h1>`;
      });
    }
    

    As you can see the first things we do is to replace the whole client side Web Part with the loading indicator and a loading message. Then once our Web Part is done and have data to render, we clear out the loading indicator before rendering our stuff. In this case it is a redundant operation to clear the loading indicator, since we are replacing the whole Web Part HTML with our custom rendering. If we had a more advanced user interface we could put the loading indicator in another of our elements and then remove it.

    And this would be how it looks like in the SharePoint Workbench, when loading for 2 seconds.

    SPFxNuggets-loading

    You can get a copy of all the code at this Github repository: https://github.com/wictorwilen/spfx-nuggets

    Happy Web parting!

  • Conference season, fall 2016, and where I'll be

    Tags: Presentations, SharePoint Framework

    Summer is over, slacking time is over, it's time to get up to speed and learn some new stuff. There's very much to talk about this fall if you're interested in SharePoint. And this fall I will do a couple of conferences as a speaker, which I very much looking forward to.

    TechDays 2016, Amsterdam

    For the first time I will attend and present at the TechDays 2016 in Amsterdam, the 4th and 5th of October. A local conference hosted by Microsoft. I will present three sessions:

    • Introducing the SharePoint Framework
    • Deep dive building client-side Web Parts using SharePoint Framework
    • SharePoint Futures - Christmas came early this year!

     

    The SharePoint and Office 365 track will be outstanding with where you also can listen to Waldek Mastykarz and Albert-Jan Schot.

    SharePoint and Exchange Forum, now SEF Unity Connect

    I don't know for how many years I've done this show, SEForum, 26th to 28th of October. It's the best conference for SharePoint, Office 365 and Exchange in Sweden, the Nordics, Scandinavia. And you'll find all the experts here, such as Spencer Harbar, Eric Schupps, Jesper Ståhle just to mention a few. This year I'm honored to do the keynote, together with Dan Holme (Microsoft). It will be a blast! And I will also do the following break-outs:

    • Building Modern Solutions with the SharePoint Framework
    • SharePoint as an Intranet

     

    If you're planning to attend, please use this code SEFWICW10 to get 10% off!

     

    If you're around, come by and say hi, looking forward to meeting you all out there on the road.

  • The SharePoint Framework (SPFx) is here!

    Tags: SharePoint, SharePoint 2016, SharePoint Online, SharePoint Framework

    Today is the day many of us have been waiting for since the big SharePoint event at May the 4th. The highly anticipated SharePoint Framework (SPFx) is here and announced in at the SharePointFest, in this blog post, as well as in the new Github repo for SharePoint. Personally I've been waiting for this even longer after being involved by the product team to give early feedback and also attending the first top secret DevKitchen "hackathons" where we could try out very early bits.

    That feeling when you use the SharePoint Framework the first time...

    The first release of many to come…

    This is the initial public preview release, officially christened the SharePoint Framework Developer Preview, is a beta, maybe an alpha, of the SharePoint Framework. This is by no means something you should use or deploy to production. Things will change! Period. There are several known issues at the moment and some of them will likely incur breaking changes. But please, build stuff and give feedback to the product team, use the Issues feature in the Github repo.

    This initial release focuses on client-side Web Parts which can, once released, be used in you classic SharePoint sites and pages as well as in the new modern user experience that is slowly being rolled out throughout the suite. As some of you know, I've spent quite some time on Web Parts and written a book on the topic, so this is something that gets me really excited.

    How and where to get it!

    All you need to do to get your hands on it is to follow the instructions on the Github repo. I'm sure we'll see tens and hundreds of blog posts on how to do it, but I recommend you to follow the one in the repo to start with. And, if you can't follow it, create an issue, make a pull request with an update - make sure we get good official documentation! Heck, I'm pretty sure I will write a couple of posts on the topic, but I will also continue to provide feedback on the framework and the documentation.

    You will find samples, documentation and all you need in a set of brand new repositories in Github, also under a brand user/organization called…SharePoint (yes, no more generic Office dev, SharePoint is back!).

    Need to know more?

    Keep the conversation going on Twitter, SharePoint Stack Overflow, the new Office 365 Community network and other social media, and do use the #SPFx hashtag. I'll try to hang around at the SharePoint Stack Overflow as much as possible, since that is the best platform of the above mentioned ones.

    I've previously written a Q&A on SharePoint Framework and will continue to update that post with details and changes in the current preview release.

    Now, go, build something awesome!

  • What's new on the Office Roadmap - 2016-05-06 (Future of SharePoint edition)

    Tags: Office 365, SharePoint Framework

    The Office Roadmap updates with the new announcements from the Future of SharePoint event has arrived (they arrived May the 4th to be precise). I'm back from the event and San Francisco and I'm full of the energy that the SharePoint team transmitted.

    You should specifically take a look at the In Development part here. That's where we got the new and fresh stuff from the Future of SharePoint event.

    Changes 2016-06-06

    Now Launched

    • Delve Analytics: Do you want all the details on how and when you work Delve Details and an E5 subscription is all you need (from in development)
    • Drive Shipping and Network Based Data Import for Office 365: Fast Track is getting more and more mature with import options (from in development)
    • FastTrack | Box to OneDrive for Business Migration: Still using Box? Get your files over to OneDrive with Fast Track (from in development)
    • FastTrack | Expanded language support: More languages available in the FastTrack (new)
    • FastTrack | Power BI onboarding support: And Fast Track Power BI is now live (from in development)
    • Multiple timeline bars in Project Online: This must be one of the features that's been jumping back and forth the most on the roadmap (from rolling out)
    • Office 365 Groups: multi-domain support: This is one of the most important feature releases of Groups. Read this article for full details and configuration options. (from in development)
    • Office 365 Reporting Dashboard: Better reporting in the admin center (from rolling gout)
    • OneDrive for Business Recent Files to Sway: Easier access to your OneDrive docs in Sway (from in development)
    • Skype for Business App SDK: Get your coding skills on and build some Skype Apps (from in development)
    • Skype for Business Mac Preview 1: The long awaited Skype Mac client is not out. Feedback on it has been moderate at best though (from in development)
    • Updated people profile experience in Office 365: The Delve profile page is now fully rolled out. I wonder if Delve will stay as the document discovery feature or if it just will be renamed to "My Profile" or "People" or something, which would make total sense(new)
    • Yammer user profile update from Azure AD: The one-time sync from Azure AD is now launched. Wonder if we ever will see a proper sync? (from in development)

    Rolling out

    • Basic Chat: Basic Skype chat from the Skype icon in mail - it doesn't say that it's web based, but I guess it is(new)
    • Office 365 Groups: usage guidelines: A very important update, this allows you to modify the usage guidelines for Groups (another feature copied from Yammer) (from in development)
    • SharePoint Online - modern document library experience: The new doc lib experience, mayhaps rolled out a bit early and without any guidance (new)

    In Development

    • eDiscovery Case Management, Hold & Permissions: more permissions control for eDiscovery and compliance stuff (from rolling out)
    • New AutoCAD file format support in Visio: AutoCAD file support in Visio… (from rolling out)
    • Office 365 Groups: search Groups files using Office Delve: Searching should now show documents from Groups (new)
    • SharePoint home in Office 365: Finally Office 365 and SharePoint will get a proper home page. The Sites tile will be renamed and now point to this page. You can read more about this feature here. (New)
    • SharePoint Online – Client-side Web Part for Existing SharePoint Pages: The new customization features announced at the Future of SharePoint Event. Client-side Web Parts created using the new SharePoint Framework on existing SharePoint pages. Read my post about it here (new)
    • SharePoint Online - modern lists experience: A new lists experience, very similar to the new doc lib experience. A great and modern looking UX. (new)
    • SharePoint Online - SharePoint Framework: The new client-side framework that will be used to make the future customizations and development of SharePoint. This is the Framework that Microsoft will build the new "NextGen" portals and the one we will use. There's much more to read about this here. (new)
    • SharePoint Online - Site activity and insights on the Site Contents page: Each site will get its own set of statistics that shows you how the site is used and what activities are going on (new)
    • SharePoint Online – Webhooks on SharePoint Document Libraries: One of the first new extensions to the SharePoint APIs. I'm glad they are using standardized Webhooks, instead of some weird remote event receivers. Hopefully we'll get the same for lists (new)
    • The new SharePoint mobile app for iOS: Announced as the "Intranet in your Pocket". The new SharePoint App will first come for iOS (actually I'm already using it) and then later for Android, and if Windows Phone is still alive by the end of this year those two users might get it as well (new)

    Cancelled

    • Class Notebook: limit sharing and deletion of section groups: This is just weird, this was rolled out the other week and is now all of a sudden cancelled (from rolling out)

  • SharePoint Framework - Questions and Answers

    Tags: SharePoint, SharePoint Framework, SharePoint Online, SharePoint 2016

    Me at The Village in San FranciscoAt the Future of SharePoint event in San Francisco on May the 4th Microsoft announced the new and improved customization option and/or development model called the SharePoint Framework. This is a development model that solely focused on client-side development. There's been some confusion going on on Twitter and other social medias and podcasts and I thought I should put together an Q&A post for this.

    This Q&A post is totally unofficial, all of this is currently in private preview and some comes from my (awesome) DevKitchen experiences, so things can and will change and I take no responsibility of any errors in this post or any financial, physical or mental issues caused by reading this.

    I will try to keep this post alive as much as possible and if you have any questions, feel free to post them and we'll try to get answer to them. I also listed some questions, that I do not have an answer to, but are working on to find out…

    [1] Updated 2016-08-17, after initial developer preview release

    Q: Is the SharePoint Framework an new development model

    My point of view here is that this is not a completely new model. The framework might be new, but that is a framework that we all has been longing for for quite some time. Client-side development has been here for years and we all built our own frameworks. Now Microsoft is creating this framework for us, it is standardized and they will also build in native support for this framework in SharePoint. This model leverages techniques we are used to such as CSOM, the SharePoint REST API's, the Microsoft Graph etc and at the same time embraces open source technologies such as node.js, Gulp, Yeoman and more.

    This model does not deprecate anything; if you need to do full trust code you can still do that (on-premises) and build WSP's, if you want to use the App/Add-in model you are free to do that.

    Q: What's not so new in this model?

    A bit of a weird question, but I wanted to highlight that this model actually piggy backs on previous development models and infrastructure in SharePoint - specifically the Add-in model. The packaging and deployment mechanism is using the add-in model. The solutions built using the SharePoint Framework are being packaged as a .spapp file, which is very similar to the .app package created when building a SharePoint add-in, and distributed using the App Catalog.

    Q: Are the Feature framework, Sandbox and the Add-in models dead?

    [Added 2016-05-08] Far from it! The Feature Framework (introduced in SharePoint 2007) is very much alive for on-premises deployment and is in many cases a requirement, with the caveat that it is hard to convert that to a model that works in the cloud. The Sandbox is partly dead, it is, code based Sandboxed solutions are officially deprecated, but there are still a usage for declarative Sandboxed solutions. The Add-in model is also still a very relevant way moving forward; Add-ins offers features that the SharePoint Framework doesn't (such as isolation, elevation of privileges etc).

    Q: Does this replace Add-ins?

    [Added 2016-05-08] No! The SharePoint Framework will NOT replace Add-ins, the will co-exist side by side. There's no need for you to migrate your Add-ins to the SharePoint Framework. That might not even be possible to do - since you want to stay in isolation, you might want to elevate privileges, you might want to do work without user interaction, you might want to use the existing store.

    Q: Do I need to create those weird app keys and secrets and learn all about OAuth?

    [Added 2016-05-08] No, this is not how the SharePoint Framework works You only run this as a user, within the SharePoint page context so you are already authenticated and the SharePoint Framework app are already authorized with the currently logged in users credentials and permissions.

    Q: Can I call the Microsoft Graph using the SharePoint Framework?

    [Added 2016-05-08] No. Not now at least. You don't get any token that you can pass to Microsoft Graph (graph.microsoft.com). The only API's you can access are the same ones as you can using any Script editor web part or script embedding. If you really want to query the Microsoft Graph, you need to create an Azure AD App and sacrifice to the gods that the Azure AD team fixed ADAL/MSAL so that it works with Internet Explorer and trusted/intranet zones, and do it the "old fashioned way".

    Q: Is there any specific requirements on my infrastructure?

    [Added 2016-05-08] No, there is no requirements on app-domains etc. as we have in the Add-in model. You can host your SharePoint Framework solutions on any web server anywhere or in SharePoint itself, without any extra infrastructure components. This also makes it very easy for the SharePoint team to bake this into a future Feature Pack (see below).

    Q: What does the .spapp package look like?

    When you package your client-side solution, an .spapp package is created. This package looks very similar to any other SharePoint Add-in you're creating. This package contains the following major things:

    • An AppManifest - a regular SharePoint add-in AppManifest with the difference that the App element has a IsClientSideSolution="true" attribute
    • One or more features - a normal Feature element file

    For a client-side web part the feature contains a .webpart file that is being added to the Web Part gallery. The client-side web parts actually use a new .NET web part class called Microsoft.SharePoint.WebPartPages.ClientSideWebPart. This web part has one important property that references the client-side web part Id. The elements file for the Feature also contains a new CAML element (ClientSideComponent) that is used to point to the bootstrap JavaScript file that we use. That file can be hosted locally (for development), in SharePoint or any other CDN (for more information see below).

    For client-side applications it is a bit more complex as they are tied to lists. For the sake of uncertainty I leave that description out for now (well I got to have a reason to lure you back here). I know there are discussions on how this should be implemented/executed.
    [1] Note that client-side applications is not part of the initial release.

    Note that none of your actual logic (JavaScript etc) is stored in the .spapp package.

    (Once again this might very well change over time when we get closer to release)

    Q: How do I deploy my solution?

    Deployment is two steps; one is to deploy the JavaScript files and artefacts (see below) and from that you get a bootstrap URL, that URL is used to package the solution (.spapp) which you then deploy to the App Catalog in your SharePoint tenant.

    Q: How do I deploy my JavaScript files and other artefacts?

    You have three options of hosting all your files:

    1. For Development you host your files locally (localhost using the node.js express engine) and can take advantage of automatic reload of your app when you save files etc.
    2. You can deploy to a SharePoint library. A good option if you want full control of the artefacts in your tenant
    3. To a CDN. This is most probably the best solution for ISV's where they centrally can manage all the artefacts.

    Q: How do I update a client-side solution

    This is an answer that some might be scared of. If you only need to update the logic or code in your app you only have to update the source files, you do not have to redeploy the .spapp package. The "only" time you would need to do that is if you change the URL to the location of where you host the bootloader JavaScript file.

    Since the app package and app registration only contains a reference to the bootloader JavaScript file, there is nothing preventing a user, vendor or similar to actually modify that file (and thus giving the app full access to the page/site - see question about isolation below). But, this is exactly the same way we have it with any jQuery or Angular files hosted on a CDN.

    Q: Will the Office Store allow client-side solutions built using the SharePoint Framework.

    Thank you, very good question. I do not have an answer to this right now, but I assume that the team are working hard on this, specifically regarding the topics around updates. To be continued…

    Q: But hey, I'm an ISV and this looks like an Enterprise developer feature only!

    [Added 2016-05-08] Thank you for asking and noting. Yes, I agree that the current initial release is focused on enterprise developers. I know one of the goals with this new framework is also to support the ISV market. I have however no timeline for this.

    Q: What about isolation in my customizations

    The SharePoint Framework runs in the context of your page, and will also have all the privileges of the user of the page. This might sound scary, but it works in the same way as any Script Editor Web Part or Custom Action with JavaScripts. If you truly need isolation in your app you have two options; 1) Go back and use the Add-in model and host your application in an iFrame or 2) build your new client-side application using an iFrame.

    Q: I don't want everyone to be able to see my business logic in JavaScript!

    No problem! Then you just encapsulate your "secret" business logic or algorithms in web services and make sure that those are CORS enabled.

    Q: What client-side frameworks are supported?

    All of them. Well, I haven't tested all of them, but that's the idea. The product team does not want to limit you with what frameworks to use, so go ahead use your preferred ones. Personally I've built client-side solutions with jQuery, Angular 1.x, Angular 2, React and Knockout.
    [1] Microsoft and the Product Team for SharePoint has taken a decision to use React in their solutions. This actually have a big effect on us developers. For instance the new Office UI Fabric version 2 - is React only! So if you want to use the new components offered you either have to use React in your client side solution or reverse engineer Office UI Fabric, since there's no "pure CSS" spec/implementation.

    Q: Do I really need to learn TypeScript?

    Short answer Yes. The tooling right now is built using TypeScript and uses class inheritance etc. It is possible to write using plain JavaScript but that would just be a waste of time and more error prone. And just because of that we'll probably see people doing this. And this makes me bring up the old SharePoint mantra - Just because you can, doesn't mean you should!

    Q: Do I really need to use Visual Studio Code?

    Short answer; absolutely not! You can use whatever tool you want to write the code. However I guess most of the demos and instructions from Microsoft will be based on Visual Studio Code.

    Q: But I really want to use Visual Studio that I'm used to and love so much!

    Yea, I'd love that option to and there's a lot of benefits of using Visual Studio. I know that the product team are aware of this and I'm pretty sure that they are working on it. But see this as an opportunity to learn Visual Studio Code meanwhile…
    [1] Visual Studio is fully supported, together with the use of the Node.js tools for Visual Studio (NTVS). Please use at least version 1.2!

    Q: Do I really need to use Gulp?

    Short answer: Yes. The current tooling is built on Gulp tasks and I recommend you to start with that. But if needed you can configure and modify those tasks. It is also totally possible of building your own package mechanism and code structure that fits your style of coding, if you have the time. (I actually wrote my own package mechanism and gulp tasks from scratch just to understand how it all worked out and to be able to give feedback to the team - so it is possible)

    Q: Does it work on my bestest device ever - my precious Mac?

    [Added 2016-05-08] Yup! Use Visual Studio Code on your Mac, use whatever text editor you like, use it on a Linux box! This is one of the reasons the team choose to use Node.js npm ,gulp and Yeoman as the foundation for the development framework and that is why the go with Visual Studio Code first (instead of the full Visual Studio).

    Q: Do I really need to use Git?

    Short answer: Nope! Git has nothing to do with this, at all. But the code samples and the source for all the tooling will most likely be distributed using Git/Github so if you're interested in contributing you should learn it.

    Q: Is this Open Source?

    [Added 2016-05-08] From my understanding the idea is to have this Open Sourced once we get out of "closed beta". There really is no point in doing it any other way with client side components,.

    Q: What is the Workbench?

    The Workbench is a test rig for client-side solutions which comes in two flavors. One static html version that are used without the context of SharePoint. It is capable of rendering the page canvas and client-side solutions so that you can work with the UX components. If you need live data however you need to create mock data for your domain model. The second flavor of the Workbench is the one running in SharePoint, with that one you have access to the full page context including SharePoint data.

    Q: What about SharePoint 2016 on-premises, will we ever be able to take part of all this?

    Yes, I do believe so. There's nothing in here that actually locks this model to Office 365 and SharePoint Online and at the Future of SharePoint event there was announced that SharePoint 2016 will get "Feature Packs" during 2017. So, yes, this will most likely happen.
    [1] Microsoft is targeting an on-premises release of the SharePoint Framework for the first half of 2017. This will be a part of a feature pack for SharePoint 2016.

    Q: When can I get my hands on this??

    [Added 2016-05-08] It was announced at the Future of SharePoint event that this will roll out starting this summer to first release tenants. My guess is that we will have a first version by the end of this year (2016).
    [1] You can get your hands dirty right now over here:

    Q: Is it SPX or SPFx?

    Over the last two days I've seen the SharePoint Framework been shortened both as SPX and SPFx. I prefer the latter one. How about you?

    Q: What permissions is needed to deploy a SharePoint Framework app?

    [Added 2016-05-10] A really good question. This is an assumption based on the experience so far. You distribute the app/solution to the App Catalog - so you need to have permissions on the App Catalog.

    Q: How does the development life cycle look like?

    [Added 2016-05-10] The development life cycle is one of the things that this SharePoint Framework would like to align with the rest of modern web development. You have multiple options and how you actually do it is up to you. This is how I see it and what works great with the tools:

    1. Build and host your solution locally (node.js Express web engine) using the local Workbench, without any real SharePoint data just using mock objects
    2. Host your solution locally as above, but deploy the solution to the app catalog and then add it to a site so you can test it with real data
    3. Iterate 1 and 2 until you are happy
    4. Pack and deploy your JavaScripts and assets and deploy either to CDN or to SharePoint
    5. Package your solution, now pointing to the CDN location, and upload that to the App Catalog to distribute it to a SharePoint tenant
    6. Repeat 4 and 5 in dev, stage or production
    7. Go back to 1 to build your next version/update

     

    Do you have any more questions? Let me know!

About Wictor...

Wictor Wilén is the Nordic Digital Workplace Lead working at Avanade. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for seven consecutive years.

And a word from our sponsors...