2 requests when creating a custom view in Volto

Development Plone 6 UI (Volto)
#1

Hi there,

We have seen that when creating a custom view for a given content in Plone where we need to show custom query results, Volto does always 2 requests to the back-end API, requesting first the content itself and then the custom query.

We are using this pattern to show a list of newsitems 26. Volto View Components: A Listing View for Talks — Plone Training 2021 documentation
the latest Volto has removed the ?fullobjects query in the getContent and we want to show the image of the newsitems. In the "items" attribute of the API result we have only the id, title, description, so we need to make a custom query to obtain the full objects. We do that doing a searchContent query and render the template (like in the pattern). So far so good. But if we load that page in the browser we see that Volto does 2 queries: the standard query to get the context content and the one we have made to search the full objects.

We have dug in the Volto code and we have seen that the View component does always a getContent call in its UNSAFE_componentWillMount, so it will be always called, regardless we are creating a new view and using the searchContent call.

Is that right? Is there a way to "not to do" the standard getContent call?

#2

fullobjects was removed as it caused a performance hit. But there is a setting that brings back the old behaviour, set settings.bbb_getContentFetchesFullobjects to True.

The second load is "normal". Let's look a bit at what happens inside Volto:

  • the View component does a getContent on its mount
  • notice that the view component computes the layout to be used based on the results fetched from the server
  • now with the layout decided, it can render your registered layout component, except that you're now doing the extra call in your custom component.

I think kitconcept.volto has some stuff to help with the preview images. For your problem and optimal performance, I think you should try to get the backend responses to have the information you need, to avoid the extra call.

2 Likes
#3

As Tiberiu said, the "standard" getContent call is what keeps all the architecture in place, since we don't know upfront what's behind a route, we need to ask for it at some point of the component tree to decide what to show.

The "items" shown without the "fullobjects" by default now are a summarised ones, taken from the default serializer. If you want to get the information from a single getContents call, you should extend that serializer to add the information you need. You can do that selectively only for your content type, using the right adapter.

You can also make another call to the @search endpoint, get the first level of items of the current path (an inexpensive call) ask only for the desired metadata. But then, you have to index the information to get the desired metadata in the @search call if it's not already there.

Another fancy solution would be to instantiate the listing block in your view, but that's another story :slight_smile:

1 Like
#4

Thank you for clarifying that.

We don't want to change the settings.bbb_getContentFetchesFullobjects just for a single page need, so we will assume the 2 requests or change the backend response to avoid the extra call.

We were worried about the performance issue because of having 2 request so I think the second option is better for us.

Thanks

#5

Nah, p.restapi is fast :slight_smile:.

Plone Foundation Code of Conduct