How to share data for all Web Parts (SPFx) within a SharePoint Online tenant?

Question

We are an ISV and developing a SPFx Web Part using the new SharePoint Framework (The same question applies for the Script Editor Web Part too). The Web Part will be added to hundreds of pages across a number of site collections. To make configuration easy for the customer, we’d like to have a central location to store the shared data (for configuration purpose) for all Web Parts within the same tenant.

So far, we can’t find a good place to store the data. We thought about using the site property bag of the root site of a site collection or a dedicated document library. Although this works within the same site collection (Web Parts can find the root site easily), it doesn’t work when multiple site collections are involved. The customer has to manually edit each Web Part in other site collections to specify where the data host site is located. As an ISV, we can’t hard code the URL to the Web Part package, nor expecting customers to modify the package themselves.

I want to know if there is a common location at tenant level where all Web Parts can discover automatically without explicitly specifying any URL. An example location at site collection level is the root web, all Web Parts in a site collection can access the same property bag of a site by using “clientContext.get_site().get_rootWeb()”. Another example is the property bag of a web application or a farm for SharePoint on-premise.

Any suggestions/thoughts will be appreciated.

Answer 1

Check the "ContentType Hub" .. it is a misguiding name

You can store whatever you want in that "Hub" Site Collection, and by default every user should have read-access

https://support.office.com/en-us/article/Activate-a-content-type-syndication-hub-1D12EE7F-77E0-4B50-BF93-7628B8478BF6

I use it to store JSON files.. but! you can't use the .json extension! Give it any other extension and read the files with the Fetch API (still needs a Polyfill for Microsofts browsers)

FYI, performance is going to be your main issue, any SharePoint API call is just dead slow,
where any modern API has a decent 15ms-30ms response time, SharePoint can take 100+ ms
and I often have worst case scenarios where it takes seconds (this in on SharePoint Online)

So develop to grab info once and store as much as possible in Session and LocalStorage

This also sucks when you want to go the modern W3C standard for WebComponents; keeping everything as separate files in an SP Library is just awful with those response times.

Microsofts solution to use a dedicated CDN works... but is just weird , and totally useless during development..
All it does is copy the contents from a SharePoint location to another (non SharePoint) location... every 15 to 20 minutes.. with mangled names

Lots of headaches this past year... now moving parts out of SharePoint to AWS

Also.. be sure to have your Legal Team check the Facebook BSD license on React.. ... we couldn't live with the fine print.. so ditched React for WebComponents

G'luck...