Chris O’Brien, fellow SharePoint MVP & and a good friend, periodically publishes a blog post of his SharePoint wish list. I look forward to and enjoy reading these as it gives you some insight into what he’s thinking and the rough edges he’s bumping into in his work. Chris is one of those SharePoint guys I’ve known for years that I always stop to listen to when he presents or voices his opinion on a SharePoint topic… if you don’t subscribe to his blog, you should!
His most recent wish list post, Office 365 developer wish list (SPFx and modern sites), summer 2017 got me thinking. I’ve got a list of things I know I want so… why don’t I post my wish list?
So here we go… my first SharePoint developer wishlist post!
- SPFx Core: Guidance on Referenced Library Updates
- SPFx Core: Open Source or at least Source Open the Yeoman Generator
- SPFx Core: Clean up the Yeoman Generator
- SPFx Core: On-Premises Update Cadence / Guidance
- SPFx Core: Add Full Page App Component Type
- SPFx Extensions: More Application Customizer Placeholders
- SPFx Extensions: Support Development in Local Workbench
(1) SPFx Core: Guidance on Referenced Library Updates
As we build components for SPFx that are run within the context of SharePoint, we can leverage libraries that are provided on the page by Microsoft. The two big examples here are React and the Fabric React.
But we don’t have the ability to control what version of these are on the page; the version on the page is a system-wide thing defined by Microsoft. When they do decide to roll out a new version, one tenant will get it at another time. At the moment we have no way of knowing when a new version of one of these libraries is going to or has been deployed to our site & that’s not good.
Looking at one of my tenants, I see React v0.14.7 which was released in January 2016 (yes, almost 1.5 years ago), but the most recent release (from June 2017) is v15.6.1.
There have been a ton of fixes, improvements, updates and new features added in the last 15 months… so does Microsoft plan to update them?
In December 2016 I asked this question (see SharePoint/sp-dev-docs #325) before the GA release of SPFx and was told it was seen as an important thing, yet here we are 7 months later. Yes, if you look at the Github issue they published some guidance, but that’s not what I’ referring to here.
The bigger issue is what if there is an issue in React / Fabric React that you have coded a workaround for, but then a version of the library addresses it breaking your fix?
This is an important topic that we need guidance from Microsoft on. Enterprises with large deployments need to have faith in what they deploy customizations to and not just let things change underfoot without any anticipation or foresight into the changes.
So, my specific “asks” are as follows:
Whendoes Microsoft plan, and if so how to update dependent libraries like React / Fabric React?I used to say when but after 15 months of no update to React, I think if or do is a more appropriate now
How will they communicate it ahead of time?
Will this differ from On-Premises & SharePoint Online deployments?
References
(2) SPFx Core: Open Source or at least Source Open the Yeoman Generator
Plain and simple, I was hoping to see the source of the generator get released. The main reason is to see how things are done and how we can possibly improve on their process.
I asked about this too in December 2016 (see SharePoint/sp-dev-docs #294) but was told that wasn’t going to happen. This is the only instance I’m aware of where the source of a Yeoman generator isn’t shared. It’s strange to me since you can see the generated JavaScript when you install it.
Why? Would be nice to contribute back to it just like we can do with the docs. For instance, the provisioned README.md in all SPFx projects is outdated, poorly formatted and still includes TODO comments from pre-GA.
I’m fine if Microsoft doesn’t want to go full open source in the sense where they take PR contributions from the community (although I don’t understand that reason), but at the very least they should do what’s considered source open where they share the source code but don’t accept PR’s & contributions.
References
- Github #294: Plans for releasing (open source | source open) the SPFx generator?
- UserVoice: Open Source or at least Source Open the Yeoman Generator
(3) SPFx Core: Clean up the Yeoman Generator
Similar to the last point, the Yeoman Generator needs some attention. Building off my README.md comment above, there are broken references to JSON schema files and unnecessary files like .npmignore.
The team just did a big refactoring of the generator and I was hoping to see some changes then, but none of these were addressed.
References
- Github #653: Why are editorconfig, npmignore, and gitattributes/gitignore included by default
- UserVoice: Cleanup & Improve the Yeoman Generator
(4) SPFx Core: On-Premises Update Cadence / Guidance
Later this year, SharePoint Server 2016 Feature Pack 2 (FP2) will bring the SPFx to on-premises customers. When this ships, my ask to Microsoft is a commitment or guidance on how they plan to update it going forward. For instance, when it ships, it will only include client-side web parts, but not application extensions… or at least that’s what we understand today.
Will we have to wait for future feature packs to get new SPFx drops or will there be smaller refreshes? Hopefully, we don’t have to wait a year between SPFx updates on premises.
(5) SPFx Core: Add Full Page App Component Type
It’s been brought up multiple times in different places, but I’m not sure if this is the same issue as other SPA-like suggestions linked to at the end of this submission. I think this would give us the ability to deploy a SPA so IMHO this could be merged with all of them.
I’d like to have a new component option for SPFx projects: full page app. I want to define 100% of what goes into the canvas, blocking the user from making any configuration changes in edit mode. Ideally, I’d like two types of pages to write to: one with & one without the QuickLaunch menu (if QL isn’t present, take up the entire user area of the page… what we used to call “PlaceholderMain”).
When a user installs the app, the page is created somewhere (maybe the Pages library) and optionally a link is added to the QL.
Think of it like this: it’s like a modern page that allows the developer to add a single web part to the canvas and disables edit / delete options for the page by designers.
References
(6) SPFx Extensions: More Application Customizer Placeholders
Today we get PageHead & PageFooter. I think we need to have before & after placeholders for QuickLaunch & PlaceHolderMain. My comment in the GitHub issue has a picture showing what I mean.
References
- Github #625: Extensions: Application Customizer - Additional Placeholders Requested
- UserVoice: Extensions: Application Customizer - Additional Placeholders Requested
(7) SPFx Extensions: Support Development in Local Workbench
Today, application extensions in SPFx (command sets, application customizers & field customizers) can’t be tested within either the local or SharePoint Online hosted workbench. This is a bummer and a big step backward to such a cool aspect to the development story with SPFx.
I get that you need a list to work with, but at a minimum, the workbench could have a static list with static data and no other functionality for us to test the customizations on.
My wish is that Microsoft adds support to the workbench for extensions before GA.
References
What Do You Think?
Do you have thoughts on the above items? Leave a comment and appropriate, head over to the Github and/or UserVoice item and join the conversation! On Github, you can voice your support with a simple thumbs up reaction (top left emoticon on the issue) or by adding votes to the item on UserVoice.
