Volto: Return additional fields for listing views

I'm now working on a custom listing view. I'm trying to figure out the pattern for providing additional fields to listing items.
Out of the box, Volto retrieves listings that return @id, @type, description, title and url
Like this:

{
 @id: "http://localhost:3000/myfolder",
@type: "folder",
description: "This is my folder",
review_state: "open",
title: "My folder",
url: "/myfolder",
}

I'd like to also return the tags associated with each listing item.
So something like this:

{
 @id: "http://localhost:3000/myfolder",
@type: "folder",
description: "This is my folder",
review_state: "open",
title: "My folder",
url: "/myfolder",
tags: ["interesting","stimulating","last one"]
}

I don't know if this is the best approach, but I know it can work.
This example: 26. Volto View Components: A Listing View for Talks – Mastering Plone 6 Development — Plone Training 2021 documentation ... showcases the use of Volto's searchContent helper.

I feel there's a nicer way* to do this but this way is documented and I know it will work.
The searchContent helper provides a way to send a custom query to the api. More important is the ability to request the fullobjects when doing the query, so I'll get my tags.

*I could be wrong about the nicer way.

React.useEffect(() => {
    dispatch(
      searchContent(
        '/',
        {
          portal_type: ['talk'],
          fullobjects: true,
        },
        'conferencetalks',
      ),
    );
  }, [dispatch]);

There's a nice new utlity that @ericof introduced in plone.volto, you need to register a utility and it can provide a list of portal catalog column names, see how the image_field is handled here: plone.volto/configure.zcml at main · plone/plone.volto · GitHub and plone.volto/summary.py at main · plone/plone.volto · GitHub

Thanks @tiberiuichim so either (1) use the searchContent helper or (2) solve it on the backend with the 'JSONSummarySerializerMetadata'. If we're playing to the skills of a frontend developer then (1) is the better option.

Avoiding full_objects is better, though. Reducing the problem, we're basically talking about "waking zodb objects for listing vs just reading their metadata from the catalog", but it goes even further: content serialization can get quite large (it includes the blocks, information about children, etc) and that type of info gets repeated across all the items in the listing.

Agreed, but may be out of the reach of a frontend dev (at least with the available patterns).

Yes, indeed, it's not in the reach of frontend developers (although I have a colleague who started as a frontend dev exclusively with React and now he's all over, poking through the backend stack).

On the other hand, outside Volto, we didn't really have a "frontend stack only" developer role with Plone.

"frontend only" solution would require this: Listing variation templates should be able to control retrieved fields · Issue #2714 · plone/volto · GitHub and the plone.restapi counterpart. But we need a champion for this.

1 Like