Forum Discussion
PnP JavaScript Core - Only for Web Parts?
- Oct 13, 2016
Hi Bradley,
Sorry to hear you had some trouble with the library - I didn't see this until someone linked it in the issues list. I took a swing at responding there, please have a look - but have also copied my response here for folks.
I have a guess at what is happening here. The usercustomaction code is executed before the _spPageContextInfo is defined on the page. If that happens there isn't much we can do. We don't "parse" the url at all, we just look for that global var.
Starting with 1.0.5 (just released this week) you can export the Web object and set it to any url you like:
import { Web } from "sp-pnp-js"; let w = new Web("https://sharepoint/sites/somesite"); w.get().then(...)
Which would allow you to determine the url to use based on a given scenario. The reason we don't try and guess at the url is that method is bound to fail too often. So if we can't find that global var mentioned above we just make the requests to /_api/... which then in the case you linked resolves to the SitePages folder.
So two solutions to try:
- Wait for the entire page to load before making the requests (i.e. using $(function() {}) or similar
- Try using the Web object directly and setting the url you want explicitly.
Please let us know if either of those are helpful.
Is there a method to set the site URL via something like $pnp.config, $pnp.setup, $pnp.storage? I explored the DOM a bit but I couldn't find something that sets the site URL.
For a bit of clarification on what I'm doing. I'm using the same app.js file in both scenarios.
The JS looks like this:
$pnp.sp.site.rootWeb.lists.getByTitle("somelist").getItemsByCAMLQuery({ ViewXml: camlQuery }).then(function(result) {
//more stuff here
});
- Load app.js via web part
- Create site page
- Create app.html with <script> tags pointing at jquery.js, pnp.js, and app.js
- Add Content Editor Web Part and point it add app.html
- Load page and app.js makes calls to the correct REST endpoints - https://sharepoint/sites/somesite/_api/site/rootweb/lists/getByTitle('somelist')/getitems?$expand=
- Load app.js via User Custom Action
- Add Custom Action for pnp.js, sequence 10100, scoped to site
- Add Custom Action for jquery.js, sequence 10101, scoped to site
- Add Custom Action for app.js, sequence 10102, scoped to site
- Load home page and app.js makes calls to the incorrect REST endpoints - https://sharepoint/sites/somesite/SitePages/_api/site/rootweb/lists/getByTitle('somelist')/getitems?$expand=
Hello Bradley !
I have the same problem here. Did you find a solution to this problem ?
Best regards,
Aurélien
- Bradley GriffinOct 11, 2016Copper Contributor
Nope, I ended up just rewriting the app in jQuery.
- Patrick RodgersOct 13, 2016Microsoft
Hi Bradley,
Sorry to hear you had some trouble with the library - I didn't see this until someone linked it in the issues list. I took a swing at responding there, please have a look - but have also copied my response here for folks.
I have a guess at what is happening here. The usercustomaction code is executed before the _spPageContextInfo is defined on the page. If that happens there isn't much we can do. We don't "parse" the url at all, we just look for that global var.
Starting with 1.0.5 (just released this week) you can export the Web object and set it to any url you like:
import { Web } from "sp-pnp-js"; let w = new Web("https://sharepoint/sites/somesite"); w.get().then(...)
Which would allow you to determine the url to use based on a given scenario. The reason we don't try and guess at the url is that method is bound to fail too often. So if we can't find that global var mentioned above we just make the requests to /_api/... which then in the case you linked resolves to the SitePages folder.
So two solutions to try:
- Wait for the entire page to load before making the requests (i.e. using $(function() {}) or similar
- Try using the Web object directly and setting the url you want explicitly.
Please let us know if either of those are helpful.
- Bradley GriffinOct 18, 2016Copper ContributorWhoops, I bet Github would've been a much better spot for this!
Thanks Patrick!