Add support for Single Page Applications to the SharePoint Framework
As an example - Angular2 provides an excellent user experience, especially when tied to Bootstrap (v3 or v4) suitable for creating immersive experiences where the whole of the SharePoint chrome is replaced (other than the top bar).
However integrating it with the SharePoint REST API framework is cumbersome and unless extensive work is undertaken to mock SharePoint the unit testing and rapid deployment is very unpleasant if possible at all.
The SharePoint framework provides a rapid deployment and unit testable mechanism for developing SharePoint functionality but is limited to single web parts and extensions.
Please extend the model so that it can be used to create single page applications in the framework of the developers choice.
Thanks for your feedback! We’re reviewing your suggestion based on the demand shown by partners and customers. We are highly interested also in the actual business scenarios behind of this request.
(Gah - no "edit post" button). Rereading @AC's original comment, I think we are saying the same thing.
I should probably elaborate / explain my comments. Originally I was bullish on a real full-page-app framework. Something where we provide nothing more than a small context object and a div and get out of the way. However the more I think about it, the less I think that is actually a great solution for people to build upon. Instead, I think I prefer the "we load the page model, and give you a blank canvas to load webparts / experiences, and an extension model for other stuff, and common "chrome" shared with all the other experiences.
It's my experience that most (not all) people don't want to necessarily write full SPA experiences with routers, custom one-off navigation, etc. Ideally, they want to create one (or more) pages that look and act like the rest of the site, but all the real estate around nav, search, headers, etc. is theirs to own. In general they don't want to reimplement (or even hook up) things like search boxes, navigation hierarchies, custom extensions that apply to other pages in the site, etc. For example, if you have created an extension that displays an HBI/MBI/LBI banner on pages and lists, it would be a pain to have to implement the whole hosting of it yourself - you want SharePoint to do that. Ideally, you would have partial page loads when navigating from page to page, rather than dumping the entire browser / js data.
Another bonus with this approach is that we don't introduce a separate development model. I think if you want a "we really own everything from page load, nav controls, routing," and so forth, a custom AAD app with access to SharePoint and other O365 workloads is probably a better place to start, and the SPFX folks would focus our attention on a solution that leverages more of SharePoint. Happy to hear comments though.
Saravana Kumar Narayanan commented
Classic Page + CEWP + Angular JS + Breeze are awesome to implement any complicated custom solution inside sharepoint but in modern page i am not able to achieve the same. It should be simple mechanism to have Angular SPA inside modern page.
@Pat - I think there are multiple versions of this floting around.
A term that is starting to foot around is FCP or FCA for Full Canvas App / Page. The first thing you mention is what I think most want. Just a suggestion canvas with no edit capabilities.
Sahil Malik commented
@andrew .. thanks. Man this is one poorly worded issue then. Also reading the comments of other below, lot of people seem to be discussing SPA vs editability .. ... anyway, I’m glad you agree that implementing SPA support is not something for SPFx to solve. Underlying frameworks already do that well enough, SPFx should do more to support those platforms.
Weird - I thought I had responded to this earlier with some clarifying questions. In my mind, there are two different things at play here. On the extreme end of the spectrum, there is the "you own the entire page" app. You need to do your own navigation, routing, headers, etc. You basically get a div, and a context object, but that's about it. A slightly different approach would be something where the page model is supplied by SharePoint (possibly with some knobs and dials like 'don't show left nav', etc.), and the bulk of the page is available for use. Possibly modeled as "here is a full width, full height canvas, feel free to populate it however you wish. It can be a bunch of webparts communicating back and forth, or maybe just a single complex part. There wouldn't be a command bar (unless one was provided), there wouldn't be an "edit" button, etc.
I feel like the latter would be more useful to people, particularly combined with extensions. Do you folks feel differently?
Maarten Visser commented
We also want this hard. Sometime you just want the whole page to bring the best user experience. We currently have a succesfull app where we do this using JSlink and AngularJS. Really, Really want to upgrade this solution to SPFx to make use of Graph And other bennefits the framework brings.
@Sahil The original post by "anonymous" above was clarified in comments. I'm in agreement with you "don't change / extend SPFx to support SPAs"... from my POV, the state of the current as is to give me the ability to create a web part and put it on a page, but remove the ability for others to edit the web part & add other web parts. Basically, give me a canvas that i can add something to "as an app" or give me the ability to do that.
Today, you can't create an application via SPFx that keeps the user from modifying the page it's on.
Sahil Malik commented
Sorry but I’ll be the dissenting voice here. SharePoint framework should remain platform agnostic and it should not do anything to facilitate SPAs. Platforms can already do this. With angular you simply use an internal location provider and facilitate spas on an SPFx page. SharePoint framework must not reinvent the wheel, and do so poorly.
Paul Tavares commented
Agreed with Marc, and just like him, I continue to suggest those that use my SharePoint apps create a single Classic site to host them. Having a full page canvas (everything below the Suite bar) is a must for applications built on and for SharePoint..
Hoping the team will introduce this capability soon.
Agreed with MarkA... for me. Let's start with MVP: one canvas where I can dictate the web part that goes in it with no property pane & no ability to add more web parts to it... done.
Let's start with nothing fancy - just give us the ability to grab the real estate we need. I will continue to use and recommend "classic" pages with a single CEWP until this capability is available in the SharePoint Framework. Most of the work I do is not a "Web Part", but an application that happens to sit in a SharePoint page and use lists and libraries for its data sources.
Julie Turner commented
Completely agree with Andrew Connell's 2x use cases... one with and one without the QuickLaunch as solutions in this space have need for both scenarios.
Bob German commented
Ideally the SPFx SPA could actually HOST the Canvas to allow building SPAs that are customizable by end users.
Another powerful option would be the ability to build list-based SPAs that have a backing list, so there's a SPA for each "form": All items, New, Update, Display. These List-based forms would benefit by spraying some of the list content on the page as JSON so a round trip to retrieve the list item(s) would not be necessary.
Allowing SPAs would be an extremely simple approach to allowing a huge array of customization options. Thanks!
(opinions are my own - thanks!)
Hi admin - over at meetroo.nl we are selling/building an application which we would love to move over to a SPA on SPFx .. bring it on..
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.