SharePoint development state in 2020: story based on sharepoint.stackexchange analysis with Power BI

The year 2020 is over and once again it's time to perform regular analysis of data at sharepoint.stackexchange. This is the fourth edition of such an analysis. 

Tools used to collect and analyze data: 

  • Power BI with Power BI Desktop - super cool tools for data analysis. If you don't have experience with Power BI, it's worth trying to see what is possible. When I first tried it a few years ago I was sooo impressed with power yet simplicity in performing data analysis and building visualizations. It works very well for both simple and advanced scenarios. I believe that everybody will find these tools useful for any kind of data analysis. 
  • DaxStudio - an extremely useful tool to test your DAX queries. 
  • Power BI Community - Power BI has a very strong community. I found a lot of answers at their forum, I even asked some questions and community helped with valid answers. That's not a "tool" but worth mentioning. I am grateful for all the answers.
  • Stack Exchange API

The source code used to gather initial data is available at GitHub. More...

SharePoint Framework with ESLint

If you're still using tslint, I have bad news for you - it has been deprecated a long time ago. If tslint works for your old projects, then it's ok. However, for new projects use eslint. ESLint nowadays supports TypeScript with help of a plugin and parser. 

SharePoint Framework build pipeline is not as fast as the JavaScript tooling world and still uses tslint as a default linter. The good news is that we can fix it!

The source code for this post you can find on GitHub here.

More...

How to access SharePoint data from Azure Function with SPFx and PnP Core SDK

This post challenge: 

We have an SPFx solution, which performs HTTP calls to our API (protected with Azure AD authentication), hosted on Azure Functions. From Azure Function we further call SharePoint endpoints to get some data. We use PnP Core SDK to interact with SharePoint. For simplicity, the API endpoint returns all list titles in a web, where we're runnning our SPFx web part.

Why PnP Core SDK? Because it's the future of PnP Sites Core library. PnP Core SDK uses a modern .NET development stack and built from the ground up to better support different types of apps, to be cross-platform, fully tested, and maintainable. Read more on the documentation here. Also, Beta1 of the PnP Core SDK was released recently, so it's a good chance to explore it! More...

SharePoint Framework development tips: enhance your developer experience for newly created components

Sometimes, during regular SharePoint Framework development, you add new React components into your codebase. Sometimes VScode behaves very strangely and doesn't provide you with needed error highlights and import suggestions. 

The problem

For example, having below code:

import { FC } from "react";

export const MyComp: FC = () => {
  console.log(newGuid());
  return (
    <div>hello</div>
  );
};

Which problems do we have here? More...

SharePoint Framework fast serve now supports library components

A few months ago I created a tool, which speeds up a regular "gulp serve" process. In a nutshell, it uses a separate webpack based build. Please read this post to learn more. Since the initial release, I've fixed a few good things and added new features. The most awaited is library components support. Read further to find out how to use spfx-fast-serve with library components. 

You can manage library components in two different ways: with a special multi-package manager (Lerna.js) or without. Lerna is not the only multi-package manager, there is also Rush.js, however I know Lerna, I wrote a blog post on how to use Lerna with library components before, Lerna is simple and has least issues when working with SharePoint Framework. More...

How to effectively delete node_modules on Windows

This post is not directly related to SharePoint development, however, you might find it interesting if you deal with javascript projects (like SharePoint Framework projects)

There is one particular thing I don't like in JavaScript development infrastructure. Well, actually I hate it. That's the node_modules folder. From one side that's a very important folder, because it contains all dependencies, from the other side, usually, it contains tons of files, and some of them are not necessary. When you need to delete it, sometimes it takes just too much time: 

And I'm not the only one!

I've tried different options and found out, that rimraf works blazingly fast (suggested in the tweet above). Even when compared with the native windows command line "RMDIR", rimraf somehow works 30% faster. 

However it's not very convenient to use it every time from a console, so I added shell command extension for convenience. More...

SharePoint Framework, webpack 4 and tree shaking

In August 2019 SharePoint Framework 1.9.x was released. Among different changes also support for Webpack 4 was introduced. What does it mean for us? It means slightly improved build speed, support for a wide range of plugins and better tree-shaking. 

What is webpack tree-shaking exactly? In simple words, webpack is smart enough to automatically remove "dead modules" (in other words unused code/modules) from your resulting bundle. It reduces the size of the resulting bundle, thus improves load performance. More...

Styling SharePoint Framework components using CSS in JS approach

Intro

A very common way of styling your SharePoint Framework React components is through the css (to be precise sass, which eventually compiles to css). Actually, SharePoint Framework goes one step further and suggests something called css-modules. As you know, for a default web part we have a file called <Component Name>.module.scss. We write styles in that file and SharePoint Framework build pipeline generates corresponding TypeScript interface for us to use inside React component as 

className={styles.myButton}

SharePoint Framework ensures that a class name will be unique, that way we isolate our styles from the "outside world" and have them scoped to this specific component:

However, it's not the only way of styling your components using isolated scopes. Nowadays the approach when you write your css styles in code (in .js or .ts files and not in .css or .scss) becomes more and more popular and has a number of benefits: More...

SPFx overclockers or how to significantly speed up the "gulp serve" command

A few months ago I wrote an article about SharePoint Framework build performance - SPFx overclockers or how to significantly improve your SharePoint Framework build performance. I've tried to reduce the amount of time the "gulp serve" command uses to re-build your code and to finally refresh a browser. I used different optimization technics for that purpose. The idea was to tweak the default SPFx build pipeline. However, those post only partially solves the problem. 

In this post, I will solve the problem from another way around (spoiler: I managed to make "serve" 10-15 times faster). 

The idea

How SharePoint Framework's "gulp serve" works? It gets your sources and outputs javascript bundles. But "gulp serve" becomes slow when your solution grows. How to fix that issue? Well, since it's slow, then don't use it! 

So this is the idea - don't use "gulp serve", use completely custom webpack based build to transform your sources into exactly the same javascript bundles which are produced by "gulp serve". 

What is the input for "gulp serve"? - TypeScript sources, styles. What is the output? - Javascript files. Can we get sources and produce exactly the same javascript? -Yes.

How it works

Some nerdy content goes below. If you don't want to read about internal implementation, go directly to "How can I use it?"

To make it work, we need custom webpack config and webpack dev server to serve webpack output. More...