Forum Discussion
Debugging SPFx App Customizer
Apparently there are some additional instuctions required for the PnP JS and SPFx to play nicely with one another. Thanks to Patrick Rodgers for pointing me to the missing key described in Using sp pnp js in SharePoint Framework - Establish Context.
A single call in the onInit() method override does the trick:
@override public onInit(): Promise<void> { return super.onInit().then(_ => { //--- ensure that the current web is used for all pnp calls pnp.setup({ spfxContext: this.context }); }); }The REST call is now forming properly. It sure would be nice to have complete, organized documentation all together in ONE PLACE. :)
Thanks again for your interest and assistance.
Hello Pieter Veenstra, Thanks for the reply.
It does indeed seem that no links are being returned but it turns out not to be what I thought. I added the console log call as you suggested like so:
PnP Call in my code
But when I went to the console tab of the inspector window in my browser, I noticed this:
Incorrect REST Call generated by PnPFor some reason it seems that the translation from the PnP call to the REST call is adding the SitePages folder to the path; it's now obvious why the call is not returning any items! If I remove the offending folder from the path and just plug the result into the address bar of the browser, you can see that I am returning the items expected (in the default atom format, but it proves that the list is there and will return rows if the call is properly constructed):
Data Returned when REST call path is fixed
So my question now is: why is the PnP.js not making the correct REST call? Have I missed a step somewhere? Am I making a faulty assumption that pnp.sp.web represents the context of the current default web site? Or is it something else?
Thanks for your input, btw. I've been doing traditional SP Development for 10 years and am still climbing the learning curve on the new "remote" platform.
>>Can you try without the select. You should get all items coming back. <<
The select is not the problem, it's not filtering any rows, only ensuring that I am only bringing back the one column I am actually interested in. If you look at the ATOM formatted results above, you'll see that I am returning 3 items, but only the URL field for each item. There are only 3 items in the list.
When I do as you suggest by removing the select, I am still seeing the incorrectly formed REST call:
Revised PnP call, per your suggestion
REST call still messed up
I still only get back the same 3 items, I just get a whole lot more fields:
MUCH more data...
So, no, the select is not the issue...still trying figure out why the PnP.js is malforming the REST call...
It looks indeed that the REST Url isn't correct.
In my code I tried this:
pnp.sp.web.lists.getByTitle('MyList').items.get().then((items: any) => { return items; });and the above worked as expected
The below call roughly does the same thing:
return this.context.spHttpClient.get(this.context.pageContext.web.absoluteUrl + `/_api/web/lists/GetByTitle('MyList')/items`, SPHttpClient.configurations.v1) .then((response: SPHttpClientResponse) => { return response.json(); });Can you double check that you have the latest version of the pnp modules?
I can't see much of a difference between your code and my code.
Ran "npm ls" and this was the result:
npm ls output
Should be the latest because I only built this project this week! ;-)
