I planned to write a blog post how to run the SharePoint Framework Workbench in a Docker container on Azure. After I found out this is currently not possible I switched the scope of my trial. Instead, I tried to create Docker container dynamically for projects based on SPFx.
There are two key takeaways explained in this post. You will learn how to build your Docker file specific for your upcoming projects, and you get to know how you can demo and try out all SPFx Pattern and Practices samples regardless the version currently needed by those projects.
My last blog post focused on the general installation and configuration of Handlebars together with SPFx. I haven’t explained much on the code I used. Now it’s time to go more into detail how to deal with Handlebar templates and the overall code of the web part.
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.
Now the SharePoint Framework has become general available I expect that it requires only to update only the npm packages mostly. A simple upgrade of the installed packages will be enough in future. During the beta phase you add to do manual step in addition to upgrade your project to the latest drop.
Yes, you read correctly. The modern team sites got image renditions or at least predefined image formats that will be used by the responsive experience of modern team sites.
Back in the past image renditions was exclusively available in publishing sites only. Well, you were able to use them in team sites too, but the publishing features had to be enabled at site collection level. In addition, classic image renditions might cause negative performance impacts. This was first spotted and documented by Chris O´Brien.
I guess this new feature doesn’t have much to do with the traditional image rendition and you are able to use it in your web part code too. For example, if you like to write a custom image gallery or develop a classic display template.
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.
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.