SharePoint Framework development tips: even more easily debug production version of your SharePoint Framework solution

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. 

The problem

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. 

This is something not possible for "ship" or "production" mode of SharePoint Framework solution. When you run bundle and package-solution with "--ship" flag, spfx pipeline doesn't generate any source maps for you. Instead, you have minified and performance optimized javascript code without any notion of source maps. 

Here is your approximate production code revealed in Chrome dev tools (prettified): More...

A new beast in SharePoint Framework development: library component

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...

Microsoft Flow beginners guides: how to detect that a page is a SharePoint news page

Modern SharePoint pages support built-in approval flows. While it's a cool feature, probably you don't need approval for all pages, but for news posts only. The question is how to detect that a page is a news post page? 

It turned out that it's not difficult at all! Every modern site page has a field called Promoted State. It holds information if a page was promoted as news or not. For regular site pages, the value of this field will be empty, for news post pages it will be equal to 1 (if a page is not yet published) or 2. The trick is to check the state of this field and make a final decision. More...

What’s new and what’s changed in SharePoint Online REST API in January-February 2019

I haven't posted about changes in REST API for a while, because nothing interesting was really happening inside REST API in December-November. But now we have something new to explore! 

Just a quick reminder, all data are coming from my SharePoint REST API Metadata Explorer. Go to the "API Changelog" tab and see what's changed in recent months in SharePoint REST API. 

Disclaimer

Please note, that all changes are gathered from Targeted tenant. Most likely these changes haven’t been officially introduced yet, use this post as spoilers to potential upcoming features. If you want to use APIs mentioned here in production, please check corresponding official documentation to make sure they are available.

Organizational News

This item was in the roadmap for a while. You will be able to "mark" a site as "organizational news source". When viewing news from "organizational news source" you will see an indication that this news is "organization news". Nice feature to distinguish global company news from department news. More...

Introducing SharePoint Typed Item - Visual Studio Code extension

When working with SharePoint as a developer you often need access to SharePoint data. If you use TypeScript you expect that all data will be strongly typed. However, it's not a case if you work with SharePoint dynamic data like lists and libraries. 

Consider the code below written with PnPjs:

sp.web.lists.getByTitle('Clients').items.get()
      .then((items: any[]) => {
        for (const item of items) {
          console.log(item);
        }
      });

or with SPHttpClient inside SharePoint Framework solution: 

this.context.spHttpClient.get(`${currentWebUrl}/_api/web/lists/getByTitle('Clients')/items`, SPHttpClient.configurations.v1)
      .then((response: SPHttpClientResponse) => {
        response.json().then((items: any[]) => {
          for (const item of items) {
            console.log(item);
          }
        });
      });

In both cases, you don't know the type of items beforehand and have to use any type (items: any[]). What's wrong with any type? In TypeScript it's considered as bad practice. Of course you can and should use any in some edge cases, but in general, it's considered as bad. With any type you don't have type intellisense in vscode, you lose type checking if you want to use your variable elsewhere. So how to fix it? 

To fix it you should create a separate interface manually and describe all needed fields. In that case instead of any you use: 

items: Client[]

While it works, it has a few drawbacks: 

  • you have to create all needed interfaces manually
  • if you have a need to access additional fields, you will have to go and update corresponding interfaces
  • if you (or team members) add a field to a list, you will have to go and update corresponding interfaces

What if there is a tool, which generates all required always up-to-date interfaces for you?

This is exactly what SharePoint Typed Item does - it takes your configuration and outputs TypeScript interfaces based on SharePoint lists, libraries and content types. 

Read further to find out how to get started with SharePoint Typed Item extension. More...

SharePoint Framework development tips: prettify your imports

The source code with samples from this post is here at GitHub.

Have you ever found yourself writing something like this in your SharePoint Framework web parts: 

import { Customer } from '../../../../../../models/Customer';
import { Utils } from '../../../../../../common/Utils';
import { Api } from '../../../../../../services/Api';

import User from '../../../user/User';
import GreenButton from '../../../ui/green-button/GreenButton';
import Grid from '../../../../../../shared/components/grid/Grid';

Above code has a few issues: 

  • Readability of such code is not at the best level. A lot of parent relative paths like "../../../" don't look good
  • It looks ridiculous to import "Grid" from "...components/grid/Grid". It's pretty obvious that we want to import Grid from components/grid. No need of one extra word "Grid". The same also applies to other imports
  • When you add a new import or refactor your code by moving into different folders, you will have troubles figuring out how many "../../" you need :)

What if I tell you that with some webpack and typescript magic we can make it look like this: 

import { Customer } from '@src/models';
import { Utils } from '@src/common';
import { Api } from '@src/services';

import User from '@hello-world-components/user';
import GreenButton from '@hello-world-components/ui/green-button';
import Grid from '@components/grid';

This code is a lot cleaner and doesn't have all mentioned issues. 

Let's figure out how to do it! More...

Building interactive feedback analysis system with MS Forms, MS Flow, Power BI and SharePoint Online

Office365 family provides a lot of services for you and your organization. In recent weeks I was playing \ working with some of them like Power BI and MS Flow.

I wrote an article about sharepoint.stackexchange analysis with Power BI. Power BI is a great tool for data analysis. With Power BI Desktop you can create great visualizations of your data and share it with your colleagues or publish on the web. It nicely integrates with modern SharePoint Online as well. 

MS Flow provides a way to automate a lot of different processes and simplify business cases. It also a very powerful tool in a different area - process automation. How to combine all of them and build something useful, engaging and interesting? That's the question I came up when I was working with these tools. Well, there are a lot of options available. It all depends on your imagination or concrete business case. I ended up with an interactive feedback analysis system. More...