The most straightforward example to make you familiar with how to create a custom SPFx Yeoman generator is to use Yarn instead of NPM as your default package manager. The approach to change the default package manager is simple, and many people already use it as there default package managing solution.
So, instead of adding the ‘–skip-install’ option whenever you start a new project just add this option to a generator.
The first step is, as always, to create a new NPM package.
Whenever you start a new SharePoint project, you might depend on external libraries. These libraries are maybe small helper tools such as jQuery or maybe like to go beyond KnockOut or React. Let’s say you want to use Handlebars, VueJS or perhaps Angular 1.x. Everything you perform the same setup steps in the same order. In my case, I start most new projects using Handlebars. Luckily I wrote my documentation to make the configurations pretty smoothly. To be honest, it is proper training but on the other hand a complete waste of time. Why not automate my personal preferences and start a new project from scratch with my settings already applied. This article takes a look at why you might consider writing your own SharePoint generator in future. [Read more]
Last weekend I had the opportunity to speak at SharePoint Saturday Helsinki organised by Jussi Roine and Jussi Mori. With more than 170 attendees and 20 speakers, it was the best place to be in Helsinki on this Saturday.
While I was checking my demos for my session, I recognised a problem that currently exists on the Online Workbench for SPFx. The demo based on my blog post on how to make your web parts responsive to the parent container. In this blog post, I make use of the Office UI Fabric grid system class names and colour the content of the web part differently according to the parent container. A method beneficial to support the responsive flow of web parts and to improve the user experience.
When I looked at the repository of my SimpleStyle Guide, I couldn’t believe that it was almost two years ago when I started this side project. Which those two years this Style Guide helped me in many projects to document all the changes in classic as well on the modern experience in SharePoint and Office 365.
Many developers in the past have use Frameworks such as Bootstrap or Zurb’s Foundation, and from a pure developer perspective, it is clear why to use them. There is yet Office UI Fabric around, but with every new framework, you need to learn those frameworks specifics.
Because it is and was so famous for the use of SharePoint web parts you might like to update some of your existing web parts to the modern experience. Whatever the reason is might by you use it; there are some things to know before such framework can be embedded safely in SharePoint Framework projects.
The modern experience is responsive by default, but it doesn’t mean that your web part will be. Especially with the new team sites and communication sites, the behaviour of web parts is as tricky as it ever was. Office UI Fabric doesn’t help you to achieve a significant user experience because it is out of their scope and offers only smaller components or full-page scoped methods, but nothing in between as needed as in web parts.
The surrounding design of a web part, for example, is defined by Office UI Fabric and even the grid system is provided by that toolkit.
When you write a web part, you might worry more about how the same web part behaves in different containers already defined by the overall page design in SharePoint.
Time to show you a trick how this container pages optimisation is possible in the SharePoint Framework and show the basics.
I guess I showed in some of my recent blog posts that it is possible to test themed web parts during development. This theme testing is currently not possible in the local workbench, but it is possible on the one available on Office 365. Let me show in this post how I did and do and in which problem might occur to your web parts too.
CSS is currently not capable of scoping the design only to a component on a web page. It is just possible through different class names for elements on the page. To avoid the inference of same style sheet classes on the same page, SPFx post-fix every class name used in the web parts CSS files. There are also hidden gems that allow you to change this behaviour dynamically as required and sometime the class names shouldn’t be renamed at all cost. Enough about the theory lets take a closer more detailed look.
The first version was only planned to give people a more comfortable use for theming tokens in SPFx projects. Today I released a new version that improves the typography in a way that Office UI Fabric currently not provides.
This new release is mainly targeted for accessibility and gives the ability to define custom classes based on the outlined typography.