Renderlistformdata lookup fields - Error during serialization or deserialization using the JSON JavaScriptSerializer

Forms SharePoint Online
#1

Hi,

I have encountered an issue with lookup fields in my form. It is referencing a parent table with a lot of items.

The call that fails is:
https://XXX.sharepoint.com/sites/XXXX/XXXX/_api/web/getList('%2Fsites%2FXXXX%2FXXXX%2FLists%2FXXXX')/renderlistformdata(itemid=1,formid='newform',mode='3')

In order to debug the problem, I reduce the parent table by deleting a lot of entities there. I could afterwards see all of those items (over 1.5mb of data) in the payload!!?? That's a lot to query for :slight_smile:

So the form is prepared to render couple thousand items in the dropdown just from the beginning?! Now that's an overkill...

But!

When I use dropdown, the control is requesting the items again anyway, wow....

https://XXXX.sharepoint.com/sites/XXXX/XXXX/_api/web/lists(XXXX)/items?$select=Id,Title&$top=36

This doesn't make sense....

How can I limit the lookup with any sort of filter before it renders? So the initial payload is reduced?

I can apply filter in fd.spBeforeRender, but it does not affect the size of "/renderlistformdata()" payload.

We have already subscribed the product, but this is a blocker now. I really need help with this one.

Thanks in advance.
J.

#2

Dear @jedrzej.dankowski,
Unfortunately, that's the only available method to load List data in the current version of SharePoint - same one is used by the default forms. You can check how the default Modern UI forms would behave with the same lookup fields, and you'll most likely get the same error. Tell me if this is not the case - we're looking for the improvements in this area!

The issue is that unlike default SharePoint forms our forms do not use all this data... As you see - we do request the items dynamically and would be happy to avoid loading them all at once, but there's currently no way to exclude, I am afraid.

I can recommend one of the following:

  1. Not use as many lookup fields. Perhaps, replace them with dropdown fields where you load data dynamically from another list? We have an example here - Populate dropdown with data from another site collection We're going to expand on this functionality in the future, most likely coming up with our own lookup solution to avoid the limitation.
  2. If you want to use these lookup fields on a form, and neither our Forms, nor default SharePoint forms work, you can try our older solution - Forms Designer. It uses older technology and has its own limitations, but it doesn't have this particular bottleneck.
#3

Hey!

Thanks for your fast response.

Modern UI does not invoke this web request, this is why we switched back. And it works with 8 lookup columns, while Plumsail got stuck on 3 columns - (of the same type).

I advice you to revise those assumptions, there might have been an improvement introduced from MSFT.

This is why I asked about renderlistformdata specifically, as its not present in Modern UI!

I will probably use sharepoint rest api to handle data aquisition to seed those dropdowns, but thats a workaround, not a db relational approach with IDs used to store data, but hardcoded values.

I would be glad to get a response according Modern UI and lack of renderlistformdata() call that fails the Plumsail Forms.

Regards,
J.

edit:

I can see some inconsistency in how forms are working. The renderlistformdata response, despite referencing the same parent columns, now does not consist of items that caused the payload to be too long.

How is this possible?

#4

Dear @jedrzej.dankowski ,
Okay, if default forms can actually handle it now - that's good news! We'll research and see if there are indeed any changes, and if there are any options - we'll do the necessary adjustments, as it is indeed very limiting, but it used to be the case for the default forms as well.

Thank you for the report! I think this might be very helpful.