Pnpjs: How to get site collection ID of any given web's site collection?

[TheShihan]

Category

• [ ] Enhancement
• [ ] Bug
• [X] Question
• [ ] Documentation gap/issue

Version

Please specify what version of the library you are using: [2.0.8]

Please specify what version(s) of SharePoint you are targeting: [SPO]

Expected / Desired Behavior / Question

How can I get the ID of a site collection? Note that I don't want to get only the ID of the current site collection (based on the context) but the site ID for any given web's site collection.

Observed Behavior

I can open any web (I have access to) with the following code. I can get the ID of the web:

          const myWeb: any = Web(fullMyWebUrl);
          const myWebAwaited= await myWeb();
          const ticketsWebId = myWebAwaited.Id;

I can do something similar to instanciate a site and get the context info, but there seems to be nowhere any ID information:

          const site = Site(fullMyWebUrl);
          const siteInfo = await site.getContextInfo();

siteInfo:
FormDigestTimeoutSeconds:1800
FormDigestValue:'0x.............,,17 Aug 2020 09:51:21 -0000'
LibraryVersion:'16.0.20322.12006'
odata.metadata:'https://xxxxxxxxxxx.sharepoint.com/sites/siteXy/MyWeb/_api/$metadata#SP.ContextWebInformation'
SiteFullUrl:'https://xxxxxxxxxxx.sharepoint.com/sites/siteXy
WebFullUrl:'https://xxxxxxxxxxx.sharepoint.com/sites/siteXy/MyWeb'
__proto__:Object

I know in server object model or the official CSOM you have the ID property on the Site class, here this seems to be not the case.
I would need the ID to setup a highlighted content webpart correctly.

Steps to Reproduce

(See above)

[TheShihan]

OK, after studying some examples, I found out that I can get the ID the following way:

          const site = Site(fullMyWebUrl);
          const siteInfo = await site.select("Id").get();
          const siteId: string = siteInfo.Id;

But maybe there is a better way to do this or you could include the ID property by default in the site object?

Also, is there any documentation regarding this select syntax - or are we supposed to find out stuff like this by looking at example code?

[koltyakov]

Id is definitely included by default when no specific select props are provided.

[juliemturner]

@koltyakov answered the code question but to comment on your documentation question

In general, select and its other similar methods are OData extensions for a REST call (i.e.. select, extend, filter, etc.). We do not in general re-document things that are included in the official Microsoft docs, however we are happy to take PR's or open to suggestions for specific enhancement of our documentation from anyone who wants to submit one.

[TheShihan]

@koltyakov ok, will have a look at your code tomorrow. From what I see is, that one must know, that the site ID is stored as "SiteId", as there was no property in my auto-complete list for this.

Regarding the documentation of select, I see, that it is mentioned on some pages, like:
https://pnp.github.io/pnpjs/sp/items/ or
https://pnp.github.io/pnpjs/getting-started/

But it is never (at least I didn't find it) explained, lik in your comment above. For example, nothing about selectis mentioned here:
https://pnp.github.io/pnpjs/odata/queryable/

[juliemturner]

https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/use-odata-query-operations-in-sharepoint-rest-requests

[koltyakov]

@TheShihan,

that one must know, that the site ID is stored as "SiteId"

Why as SiteId? No no. :) Provided in a code sample { Id: SiteId } means that we take Id out from the result object and use SiteId as an alias variable. That's just the JS feature, could have been const { Id: anyVariableName }.

[TheShihan]

@juliemturner yes, but this is general SharePoint documentation, you think it wouldn't be a benefit if the documentation at pnp.github.io also would include something about this? We cannot assume that just because something is documented generally in SharePoint it also works in PnPJS.

[juliemturner]

That is an inaccurate assumption. This library merely provides a fluent "language" for those libraries ergo the official documentation in general is the basis upon which we extend. There is absolutely no way that the maintainers of this library can also redocument and maintain all the REST documentation that exists in the formal documentation for the REST endpoints and we don't try to, instead we provide documentation on using this library specifically.

That said, historically many of the consumers of this library have extensive experience with the REST endpoints and so are familiar with the patterns. It may be useful to point inexperienced users to the official Microsoft documentation in the Getting Started section.

[patrick-rodgers]

Going to close this as answered. Thanks all for the discussion.