Create models for Search

[pkbullock]

Category

• Feature request

Describe the feature

• Add the ability to call the search APIs
• Unit Tests for calling the APIs
• If there are special requirements or permissions with this model, add to the documentation

Contributing

We encourage and welcome contributions for the PnP Core SDK, if you are interested, please comment below to engage with the team. If you want to learn about how to get started, please refer to this guide: https://pnp.github.io/pnpcore/articles/contributor/readme.html

The team is constantly improving the guidance on supporting contributors, if you have any feedback or need help please feel free to start a discussion.

[pkbullock]

Just for info - In message centre - MC235978 - "As part of this configuration change, users who run queries using the StartRow parameter (at rest API) with values exceeding 50,000 will be throttled. All queries using StartRow (< 50,000) - will not be impacted."

[jimmywim]

One thought, that aligns with the philosophy of one public API calling SP REST or Graph where necessary, is a single entrypoint for a search call that can do either Graph or SharePoint - but the request objects and response body schemas are drastically different, including how a request is built depending on if you're searching mail, calendar, SP or external items....

Might be worth, in which case, to have two separate search APIs? One for SP Rest, one for Graph.

Another thought - I do like the simplicity of invoking search in @pnp/pnpjs- so in C# it would effectively be an extension method on Web, for example:

var results = await context.Web.SearchAsync(new SharePointSearchQuery {
  QueryText = "contoso",
  SortList = new List<SortOptions> { Property = "Lastmodifiedtime", Direction = Descending }
  SelectProperties = new List<string> { "Title", "Path", "RefinableString01" }
});

results.RelevantResults.... etc

A trick is going to be using an Expando or similar to be able to make available the values of the properties selected in the query.

[spplante]

This feature request is underrated, most SharePoint solutions are based on the search so being able to use the search API should be in the top priorities for the SDK in my opinion, I am actually quite surprised to see many specific features getting available but nothing for the search yet, especially when the whole search API is now available in Graph.

That would be a great addition!

[jansenbe]

@spplante : this project is for a big part run on folks spare time contributions, so people that contribute often focus on the things they'd need first in their projects. That being said, being able to call search indeed is important and will be something we'll have to add.

[spplante]

@jansenbe I totally get this, I was just surprised as I thought that the search would be a big part of what people need first in their project, but having played a lot with the search API I understand it is a big piece to tackle and a small project on its own!

[DaleyKD]

Let's just say that I've done enough over the last decade with SharePoint Search and KQL and FQL to know how much I hate it. 😄 As much as I know that people need this part of the project, you won't see me gearing up to do it anytime soon unless my company needs it drastically.

[jimmywim]

I had a quick look at this a while ago (being familiar with the search API) but it was quite tricky to use the existing request model in place, the search stuff might have to have its own request handler complete with serialization/deserialization, just reusing the access tokens from the context.

[jansenbe]

@jimmywim / @DaleyKD / @spplante / @pkbullock : Basic search has been added, docs to follow soon