Help us to help you! What are the SharePoint Framework adoption blockers?


Please help us to help you by providing us input around different challenges or gaps you are encountering with SharePoint Framework. 


  • What are the capabilities which would help you to adopt the modern SharePoint development practices?
  • What functionalities are missing?
  • What kind of documentation or guidance would be needed?

We'll use this input with our prioritization around engineering and documentation efforts. Thank you for your input advance. 

9 Replies

@Vesa Juvonen, That is the right question at the right time ;)


I just had a discussion with some of my colleagues, where I've tried to sell SPFx (and they are all open to it!). One question I couldn't answer is here:


Some backgorund:

- The customer uses Azure SAML Service for authentication. 

- We will have data stored in SQL Databases in Azure

- An app needs to be created (My preference is a SPFx web part).


Is this scenario going to work with SPFx?




Having tested out some of the SharePoint framework samples both hosted and localhost ( with a bit of help from that Dev Jedi Master: Waldek!), I think perhaps we need few real world examples, say  forms built with React, Angular or whever that show validation,  populated list drop downs (not in the property pane this time) and extensive use of  the  Office Fabric Components, Patterns and 3rd party JS libraries such as Moments.  The data inputed could be displayed with different types of view.  Please  Keep up with the PnP shorts as I found these very useful and can these  even be prequistites for learning the future real world samples.


The real world scenarios / examples will help with estimating work for clients and what are the knowledge gaps . 


How about accessibility and SPFx? Or maybe that is even a question for SharePoint in general.

The problems mainly are not around the SPFx, but about the whole modern UI which is not yet complete and missing:

  • deploying web parts globally
  • extensions availability on all pages and more placeholders to include top, bottom, left nav, toolbar row
  • modern page templates, e.g. publishing pages
  • site templates for groups, teams
  • workbench page with standard layout (including left nav, top nav)
  • extension for SharePoint page /_layouts/15/sharepoint.aspx
  • extend news functionality, e.g. add tagging, liking, comments.
  • add a possibility to extend Delve to include the same top nav, footer, e.g. extensions


The whole problem is that it is missing consistency in Office 365 and number of features which are on classic mode.




The first major thing that comes to mind is the version of react used: 0.X.X

Any plans on upgrading the yeoman generator to a most recent version, or at least provide a easy upgrade path?

Not a true developer, nor expected to be. Knowledgeable enough to use "basic" technologies like HTML, CSS, JavaScript to complete simple solutions (typically done in a script editor web part). Now having to learn too many legit complex developer tools and techniques.

Not a knock on the tools and techniques themselves, more power to the people that can and do take the time to learn them, but I feel in general that the "citizen developer" has been decimated by the SPFX.

Just checked the blog post below from Stefan Bawer and I think it would be nice to have the yeoman generator asking the question and adding the file to the project automatically. 

Excellent question, wonderful to be asked.  I'm a little late to the party, I know, but here are my thoughts:


//What are the capabilities which would help you to adopt the modern SharePoint development practices?//

Make the SPFx consistently and seamlessly "work across": across page types (modern/classic/publishing) and across On-Premises and Online. I know that FP2 is supposed to make the latter possible for web parts, but analysis of some recent changes to the yeoman generator seem to point to a separate project type for On-Premises, which would be a mistake.  In a hybrid environment, no developer is going to want to write the same web part twice. For extensions, they need to work across page types -- if you have a standard footer you want on every page, you are currently out of luck if all your pages are not modern ui.


//What functionalities are missing?//

Forms. Forms, forms forms. Yes, I know, PowerApps...but really, this is not a viable solution for anything with really complex requirements (great for citizen developers, though).  We need something in the framework that is TS/JS/HTML/CSS that allows us to quickly and simply save whole pages of entered data as separate fields or alternatively as a complete JSON object in a single list field.


//What kind of documentation or guidance would be needed?//

The documentation, while better than even just a few weeks ago, is still woefully inadequate for a beginner.  The "description" column needs to be filled in for each entry. And examples that are *meaningful* need to be added.  We need to know not just "what" is in there, we need to be shown "how" we should use it and most importantly, "when" and "why" we would want to.  I know that this stuff is hard and a big expense to the company, but really it should be considered part of the cost of doing business.  Updating the docs to match new changes should be part of the release process -- if the docs aren't ready to be updated, the software is not ready to release! This is particularly important now that changes come so frequently.  No one should have to go out to trawl the internet for posts on how to do basic stuff, because things change quickly and those posts become outdated.  If the docs are kept up to date with the software, this problem goes away.  Additionally, some focus on past vs. future for long-time SP Dev's would be welcome; something like "if you used to do this <C# code>, now you would do this other thing instead <TS code>".


Thanks for listening!

@Vesa Juvonen, do you know if there will be any good "SPFX for dummies" going on at Ignite?  I'm thinking something like a session to walk users (non-traditional-developers) through what is actually going on to build simple solutions in SPFX?  


Skill level of someone like myself would be: knows Javascript, HTML, and CSS enough to be armed and dangerous, but doesnt understand the dev techniques and phrases described in the help/documentation (yo, gulp, typescript, etc)


At this point, I've been able to take the modern Script Editor Web Part, and basically keep doing things the way I always have been (for better or worse)