The new SharePoint Framework has a smart way to avoid conflicting CSS definitions. Therefore all style sheet classes will be post-fixed with a unique random string and converted to a JSON object. In your web part code, you can use the same class name as you used in your style sheets and the variable will be automatically replaced with the random class name string. So far the good parts of the SharePoint Framework.
In practice, this has some limitations and challenges.
I believe one on the most used front end tools in the web development world is out there is Moustache or Handlebars. It is easy to use; you can write native HTML and compelling too.
In the SharePoint world, many web parts directly show data on the page, and therefore this is the right weapon of choice to get fast going.
Right after the first version of SPFx become public available, I created a ticket in GitHub on how to use this front end tool. With the RC0 drop of the framework, a new functionality has become available that allows you to embed Handlebars through a so-called webpack loader. I was pretty excited when Pat Miller tweeted me about this.
Let me show and explain what steps are required to make use of it in your next project.
It’s been a while since the first release of the SimpleStyle yeoman generator. In the mean time some smaller releases happened and things have been patched up.
Recently I made some additional enhancements that now lead to the release of version 0.3 available now to install.
The following improvements have been made.
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.
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.
Not so fast… As announced at the May the 4th event there are a lot of new technologies that come to SharePoint and you can pick your personal flavored framework to enhance the SharePoint.
Some things of the upcoming changes are already available in Office 365. Things like the hidden web parts or the new document library. Time to rip the components of the new document library apart and show you what was used to build it.
The new document libraries are built with the following three core components:
In addition a React-based implementation of Office UI Fabric will become available together with the new SharePoint Framework.
You might have heard the Unix Bash Shell is now coming to Windows. To be more specific a whole Linux sub system based on the Ubuntu distribution comes to Windows. This addition to Windows was announce at this years Build Conference and I knew exactly how this would match to my clients and other people in the SharePoint Community. Especially with the new SharePoint Framework you should know this option because it makes many things easier using NodeJS on Windows.
Let’s take a look in the future of web development and the upcoming new web standard called web components. In the future everybody can introduce, enhance the document object model through custom elements or change the behavior of existing HTML elements.
Let me give you a brief overview what the actual ingredients of web components are and how this will improve how you write your code in the future. You will also find some wild guesses on the new SharePoint Framework.