You have a custom SharePoint Site Design, which executes (through MS Flow or Azure Logic App) PnP Provisioning process. You want to notify users that the site is not fully ready yet and it's still being updated (by background provisioning, which might take a long time). One option is to use two-way interactive communication between the SharePoint web site and the job using SignalR. That's something we're going to explore in this post in great detail.
Check out below short video, which demonstrates the resulting UX we're building in this post:
The video was cut because the actual process takes 7-9 minutes on my tenant.
Read further below to find out how to setup everything from scratch.
All sources, as well as brief configuration steps, are available at the GitHub repository. More...
- Microsoft Flow - one piece
- Power BI report - one piece
- Modern SharePoint Power BI web part - one piece
- Mikael Svenson's post - Working with Hub Sites and the search API - one piece
Well, actually we don't need any specific preparations. Just have a cup of tea or coffee if you wish :)
The idea is that we query all hub sites and associated sites into a SharePoint list on schedule using MS Flow. Then we use Power BI with SharePoint as a data source to read hub sites data and visualize it on a report. More...
At the end of September 2019, Microsoft released The Graph Toolkit library.
a collection of reusable, framework-agnostic web UI components that work automatically with Microsoft Graph
It was in preview for a while, now it's in GA, thus it's a good time to start exploring what is available in this library.
Let's explore how to use this library with a React-based single page application and with SharePoint Framework. More...
Today's post will be about SharePoint Framework build performance. Especially about "serve" command, because it's the most frequently used command among developers. gulp serve is a kind of "watch" mode for your SharePoint Framework solution. As soon as you update a file, it will spin up the build process and will refresh your browser finally, so that you can see changes.
However, from here and there, I hear complaints about the poor performance of gulp serve command, especially if you have more than 10 web parts in a solution, or if your webparts are quite complicated (with lots of code and \ or additional heavy dependencies). Checkout Gulp webpack slow build and Long build times for SPFx projects with many components GitHub issues as well. I'm also not satisfied with the build performance in case of medium and of course big SharePoint Framework solutions. In a few recent weeks, I spent some time trying to go deeper and understanding all possible ways on how to improve performance for gulp serve command.
Read further and you will find a list of tricks, which reduce the amount of time to build a common SharePoint Framework solution. By build I mean serve or bundle (without --ship parameter) command, because they are very identical. The only difference is that serve is never-ending and has an additional step which refreshes your browser. In all other cases, they are the same, running tslint, typescript, sass, webpack, copy assets, etc. tasks. I will start with the easiest tricks, going to more complicated technics. I don't use any heavy hacks here.
At the end of the post, you will find a detailed report on how any particular trick reduces build time on the example of SharePoint Starter Kit:
This is a solution designed for SharePoint Online which provides numerous web parts, extensions, and other components which you can use as an example and inspiration for your own customizations.
It contains 20+ webparts and quite slow when you use gulp serve command. Which makes it a good candidate for improvements. More...
Including the latest versions of React, TypeScript, etc. ?
SharePoint Framework is supported not only by SharePoint Online but by on-premises SharePoint as well (2019 and 2016 with Feature Pack). SharePoint Framework Yeoman generator has different options for different SharePoint versions and it generates different project templates depending on the environment selection.
On-premises SharePoint is always behind SharePoint Online in terms of features and codebase. And the same issue applies to SharePoint Framework. If you generate a "Hello world" SharePoint Framework web part for SharePoint 2019, you will see that it uses React 15.6, TypeScript 2.4 and Office UI Fabric React (OUIFR) 5.21. The most recent versions (as of today, August 2019) are React 16.8.6, TypeScript 3.5.3 and OUIFR 7.21.0.
Now you see the issue - you always have to work with an older version of packages. You miss a lot of potential features, bug fixes, and other things. Additionally, from a developer perspective, it's not exciting to work with outdated technologies or frameworks. The situation will be even worse in 2020 when we see React 17, TypeScript 4 and OUIFR 8. Will Microsoft update yeoman generator for on-premises to add support to the most recent version of packages? I don't think so. On-premises are not in the priority list today.
For those who want to jump and explore the code right away - the full source code for this post is here at GitHub. More...
Hydra is attacking porcupine? Well, actually not. Because Hydra is Lerna.js and porcupine is a SharePoint Framework solution with library components. Most likely you've heard about SharePoint Framework and library component, but not about Lerna. Lerna is
Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.
Now it becomes a little bit clear what is Lerna. However, how does it correlate with SharePoint Framework and library components?
Actually, you're not limited in using Lerna with library components only. If you have a few separate SharePoint Framework solutions in one git repository, you can add Lerna to simplify package management. More...
This is a small tip for anybody who hates typing
yo @microsoft/sharepoint because it's too long and error-prone (or you're lazy like me :)). Check out below animation:
What if we can simply type
sp in order to scaffold the project? Well, we are in 2019 and of course, it's possible :)
NOTE: Solution windows users only. Sorry MacOs :(. I'm pretty sure there is an alternative for Mac as well, but I'm not a Mac user.
Almost a year ago Waldek Mastykarz posted a great article on how to debug your SharePoint Framework solution in production, where all the code is minified and source maps are not available. While it works, there is a manual step of uploading source maps in google chrome's dev tools, which isn't very convenient. I extended Waldek's solution with fully automated implementation without any complexities.
When you package your SharePoint Framework solution, spfx build pipeline minimizes and optimizes all your TypeScript code. It's not a problem for development, because in "serve" mode spfx build pipeline generates source maps for you. Source maps allow you to open original TypeScript source files in browser developer tools with full debugging experience.
Here is your approximate production code revealed in Chrome dev tools (prettified): More...
SharePoint Framework 1.8 is out and gives us a lot of new things. Check out SPFx 1.8 release notes to learn more. Among different generally available features, we also received some items in "beta" mode. One of them is a library component type.
Library component currently is in preview and most likely will be generally available in SharePoint Framework 1.9
Let's find out what is that library component, when and how to use it. This post is not a step-by-step tutorial (you can find tutorials in the links section of the post in the very bottom), but rather an explanation of why and when we should use library components, why they were added to SharePoint Framework. The original entry in SharePoint User Voice received a lot of votes, thus this feature is long awaited. More...