While working on a responsive design project based on SharePoint 2016. I discovered a nice workaround how to remove the “Read more” tag. Since SharePoint 2013 the collapsed task form is an issue to many customers. It hides by default some important fields of a task and the extra click you have to do is not that nice at all.
Last year I released a style guide generator for your SharePoint and Office 365 development.
This year I proudly present a yeoman generator that helps you to get started faster on your next project. There is no need to clone the old repository anymore. Simply create a new project as needed based on this template engine.
To be honest the old version of the Simple Style Guide is currently outdated and shouldn’t be used anymore.
The new SharePoint Framework has a safety net when you develop and style your components. Whenever you write a new style sheet class this will be picked up by a SASS preprocessor that first compiles the SASS file and then applies a special random string to the class name.
This should theoretically avoid that two web parts have conflicting style sheet classes. If one web part uses the style sheet class ‘item’ and another web part uses the same class name. The last web part embedded on the page will win the battle how the item should look like. Through this renaming you make sure that every web part has an individual definition of the item. In general this is a good behavior.
On the other hand, you have frameworks or Office UI Fabric where those classes won’t be renamed.
There are also some negative impacts caused by that method and there is also an easy way to disable this renaming of style sheet classes. If you do so, then you need to be aware of certain things on how to make your styles available exclusively just for your web part.
The SharePoint framework improved a lot during the last drops. I thought to myself what fancy sample can I build using the framework. During the Hackathon at the European SharePoint Conference we saw a lot of great uses of this new framework. One team was even able to add a framework web part to SharePoint 2007.
Actually, last weekend I came up with an idea. It was more a proof of concept I would like to try. I asked myself the question. Will I be able to drag and drop data between two individual web parts.
Project versioning as we used to know it was not a big challenge. Not as long as you only used Visual Studio.
The thing is that assigning a proper version of your SharePoint Framework project is more tricky than simply apply a single version to it. There are more than one version of your project, that doesn’t match and have different purposes.
With every new drop of the SharePoint Framework it seems that always the same procedure needs to be executed to update existing projects.
npm is capable of scripting. To be able to execute a script, it needs to be added to the ‘package.json’ file.
Open the ‘package.json’ and look out for the script section. To register the update script create a new entry “update-spfx” and chain all commands delimited by ampersand together.
"build": "gulp bundle",
"clean": "gulp nuke",
"test": "gulp test",
*** Update 21.09.2016 for Drop 4 of SPFX use the following update-spfx command ***
"update-spfx": "npm install @microsoft/sp-client-base@latest @microsoft/sp-client-preview@latest --save & npm install @microsoft/sp-build-web@latest @microsoft/sp-module-interfaces@latest @microsoft/sp-webpart-workbench@latest --save-dev & npm prune & npm dedupe & gulp nuke & gulp"
Now you are ready to execute the following command
npm run update-spfx
After all the steps have been finished, you are ready to go with your new drop of the new SharePoint Framework.
If you think it feels like hacking. Well, it is the normal way to handle such things in NodeJS.
For the next drop or a version of the SharePoint framework you just need to execute the script again. In case something have changed please check out the documentation or simply modify the update script to the changed requirements.
How it works
Like mentioned before you can chain all the commands together. The first part contains
npm update. After the update you can specify all the node modules you like to update. You can simply add all packages right after the update and don’t need to update them individually.
You also don’t need to fumble around with the package versions the
npm update command does this for you.
I this case we had three packages to update.
Right after the package name you see and additional @-sign. This defines to which version you like to update. ‘@latest’ indicates the latest version which actually is the version of the current drop. Luckily, there is only latest version with every new drop.
The next commands that needs to be executed are
npm prune, followed by
npm dedupe, followed by
gulp nuke, followed by
In case you like to make sure you really rebuild your project can use
gulp build. This will explicitly call a rebuild. The next update can come and you only need to execute
npm run update-spfx again. Before you execute you should definitely check if something might have been changed.
In this case you can add or modify the commands.
Final hint – npm rebuild
The new SharePoint Framework contains a lot of binary components. Those components needs to be rebuilt / recompiled on your client first.
Sadly rebuild only happens when you install a package, but not during an update. The additional command that needs to be executed in this case is.
Optionally you can change this command to your
npm update script too. In this case make sure that all those components are freshly built. Eve if not required it won’t hurt your installation.
When you are working with SPFX and you start it with
gulp serve, it takes some time to start. During this startup many things happen but there are not clear indication if SPFx is working or what it actually does.
Once the workbench was started you see all the gulp task that will be executed with or without error and what it actually does.
The background tasks are well hidden, but you can take a peek into those background activities. It’s just a simple trick, but I use it every time now when I work with SPFX now.
gulp server and add the command line option
--verbose. Execute SPFx with:
gulp serve --verbose
Now the hidden world and architecture of SPFX will become more visible. In additon you get sometimes many additonal informations what might goes wrong.
From my point of view, it is easier and helps with debugging.
I will also see if the issue is caused by your configuration, code or locate a problem with SPFX.
This was actually the first question I asked after the new framework has been released. Since then there has been an ongoing discussion on that issue.
When you created a new project using a yeoman generator you’d expect a proper gulp/grunt/whatsoever file that list all the task required to build and develop the project.
When you open the gulp file of the new SharePoint Framework you see just the following lines of code.
const gulp = require('gulp'),
build = require('@microsoft/sp-build-web');
The rest of the SharePoint framework is well hidden and deeply nested inside the
node_modules folders. Theoretically, you can whatever you like in this folder, but your changes will get lost whenever fresh version will be checkout out form the source control and/or
npm install will be exited, upgrade your project to the newest drop of the SharePoint Framework or install an updated version of any package. The
node_modules folder is the
_layouts folder of the new SharePoint Framework but you can be sure that files in there will be always replaced.
My mate Waldek wrote a great blog post on how to extend the SharePoint Framework with a custom build task.
I think his article is suitable for a deep integration in the SharePoint Framework. From my point of view, it solves a problem that exists because of the Framework.
I working with yeoman generators for more than two years now and I’ve never seen a gulp implementation that only contains of a simple function call. The new SharePoint Framework follows in this case a pretty uncommon approach. I was clueless for a while.
In SPFX everything is built on gulp and it turn’s out that adding a custom gulp task is much simpler than I have expected. However, sometimes it is hard to see the forest for the trees.
Let me explain how to accomplish the same thing Waldek describe just by standard gulp methods but first let me explain some basics.
On July 29 Microsoft announced that they will completely remove of code-base sandboxed solution support in Office 365.
The main problem is that many of those SharePoint solutions just deploy XML based artifacts but no binary code.
Nevertheless I think many of those sandbox solutions deploy an empty dll to Office 365 especially when they are developed in Visual Studio.
This unwanted dll can be simply avoided directly through the correct configuration of your Visual Studio.