I am pretty excited that finally the first version of the open source community driven SPFx generator has been released last Thursday and publicly announced and is part of the SharePoint / Office 365 Pattern and Practices Personally, for me, it was a great journey to bring this to life in collaboration with Microsoft engineering.
It was a longer journey than expected but there were some considerations and decisions to make to have a solid fundament for future improvements and to allow fast and easy integrations.
When you write a new web part with the SharePoint Framework you might create a genius web part, where all the business logic is compiled into your web part. This approach makes sense when the web part is an isolated piece of work.
Sometimes you like to write pretty simple web parts that only access a backend or third-party API from somewhere on the Interweb. In this case, you can write all the data access inside your web part. Give the user the option to store APP Key, APP Secret and particular access token directly in the web part. Might pre-populate some of those properties of with your company-wide secrets and API keys too.
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.
In my first blog post of this series, I discussed how many intelligence you need in your web part when it comes to third-party API. Sometimes it makes more sense to remove the business logic out of the web part and use web parts just as the presentation layer. In the previous post, I also mentioned that might Azure Functions can be beneficial.
The Azure Portal is capable of implementing any Azure Function directly on their user interface, but there is also another option. It is possible to write Azure Functions nowadays locally and deploy them later to the cloud. This approach is in most cases more convenient, less error-prone and more comfortable to debug directly from Visual Studio Code for example.