Without a doubt, the SharePoint Framework is one of the most successful adoptions and customisation models that has ever found its way into SharePoint, and there are reasons for this.
Over the past years, I talked and worked together with many developers that haven’t ever touched SharePoint before or found its way into this Application.
Many of those had a background in C# while, especially for a branding project, was more living in the web world. The overall feedback was that it is this kind of development unique in many ways.
I firmly believe that the Yeoman generator provided by Microsoft is a great tool. It serves all the capabilities to create new web parts, extensions and customisations in the future. With the current support of ReactJS, Knockout and bare-bone HTML version, you have three great possibilities.
This PnP/SPFx generator project goes beyond these possibilities and supports enhanced functionalities. A way to add additional capabilities in the future not even for new frameworks and libraries on the market. It also helps organisations to defined their development standards.
It has been a while since I release the last version of my spfx-uifabric-themes npm package to make it easier to handle theming in SPFx projects.
New Release spfx-uifabric-themes
I’m proud to present now a new version that supports theming through CSS variables instead of SASS variables. If you hear this the first time, let me give you a short introduction on that.
You might have recognised that the workbench of the SharePoint Framework has a responsive design tester included. In this blog post, I take a look what possibilities we have to properly test the responsiveness and the user experience of a web part.
There are also some pitfalls included if you entirely rely on the integrated too.
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.