Sp-dev-docs: Additional property on context: Site absolute URL

Created on 1 Sep 2016 · 11Comments · Source: SharePoint/sp-dev-docs

It would be useful to also add the site absolute URL property to: context.pageContext.site

Currently, it only has the site ID. Site URL would make rest calls easier or search queries easier.

spfx-general uservoice-request

Source

estruyf

Most helpful comment

I see. So there is a bunch of context info that we grab that is not yet exposed through the OM (that's an ongoing project). For now, try adding the following code to access the properties

(window as any)._spClientSidePageContext.spPageContextInfo

Note that the properties in the classic page and the workbench are not identical, which is why we want to promote most of them to the API, so we can ensure that they are present.

patmill on 2 Sep 2016

👍3

All 11 comments

In general it's a bad idea to use absolute URLs in your REST calls. The digest cache changes for each URL, and you'll wind up with extra round trips.

patmill on 2 Sep 2016

@patmill I think @estruyf refers to using the site URL in the search query (like path:https://contoso.sharepoint.com/sites/abc) rather than in the REST URL. Am I right @estruyf?

waldekmastykarz on 2 Sep 2016

@waldekmastykarz exactly what I meant, and of course, it could be useful for other things too.

@patmill it would be great to align with the _spPageContextInfo object we have right now in SharePoint. This contains a lot of useful properties.

estruyf on 2 Sep 2016

I see. So there is a bunch of context info that we grab that is not yet exposed through the OM (that's an ongoing project). For now, try adding the following code to access the properties

(window as any)._spClientSidePageContext.spPageContextInfo

Note that the properties in the classic page and the workbench are not identical, which is why we want to promote most of them to the API, so we can ensure that they are present.

patmill on 2 Sep 2016

👍3

@patmill already did that for now, that was also the reason to mention this as an improvement.

estruyf on 2 Sep 2016

Ah, got it. Yes. We're looking at doing two things in this area.
1 - have a consistent set of properties in "classic" SP, the new SPFx world, and via REST endpoints. Right now it is a bit of a mess to be honest, with each codepath choosing a different subset of the properties. Hopefully the names for the same objects are consistent.
2 - move all of the properties that make sense into the context variables in SPFx

patmill on 2 Sep 2016

Adding @weshackett to this issue, since he was asking for additional properties. Diving into the inner workings of SharePoint, It is worth pointing out that the "default" properties need to be scoped to things that come back from the FetchDocForHttpGet call deep inside SharePoint. Essentially the information that hangs off SPContext.Current that doesn't incur additional round trips to the database. For a bunch of the extra user properties (say your Yammer information), that will always require an extra fetch, and won't exist by default. We'll need to figure out the right way to fetch that information on demand to make it easy to accomplish, but also have the developer realize that there is some cost associated with grabbing it.

patmill on 2 Sep 2016

@patmill could there also be an option to specify which properties do we want pre-flighted? Suppose I am building a very SharePoint specific webpart, I would really have no use for the Yammer url or the Graph Url. And that would mean the roundtrip to the database for no real benefit.

Could we specify in the config.json or manifest.json something like PreflightO365Properties:true and only then then have these properties available.

vman on 2 Sep 2016

We considered that, although it added complexity to the overall system, particularly around partial page navigation when you wanted those properties.

What we want to settle on is a pay-to-play approach where you can ask the context to load those properties, and if they haven't been loaded it will go off and fetch them. If someone has already asked for them, then no additional work will be done. it should be fairly easy to hook that into the OnInit phase of a given webpart.

The downside to this would be that the fetch requires the webpart bundle to be loaded, parsed and executed, which could delay the data fetch. There could be a future optimization there.

patmill on 2 Sep 2016

Closing old issues. The original request here is served by the following code - context.pageContext.site.absoluteUrl

patmill on 24 Feb 2017

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues