Hi, I'm looking for advice on how best to extend/modify the output of the delivery API for specific document types. Here's the secenario: We got a carousel on the home page that shows cards that promote various pages within the site, or link to other sites. Currently, the carousel is implemented as a block list with an single Card element. The card has title, text, and link fields, which have to be filled in manually. What I'd really like is, that if the user selects an existing content page as the link, that the title, text and thumbnail image are pulled automatically from THAT content page, rather than having to be re-entered. This would probably look like two different types of cards: a manual card, and an automatic card. The manual card has all the existing fields which are marked as required. The automatic card has a content picker instead of a link property. Questions for the community: - If you have a content picker property, how easy is it to "update" other fields on the same element with data based on the item picked? - Once the link is selected, can I extend the delivery api somehow so that when it's rendering my automatic card, it goes and gets the properties of the linked item and exposes them as fields without requiring the "expand" property or an additional call to the api? Any other thoughts or suggestions? https://cdn.discordapp.com/attachments/1334453829462261822/1334453829927698442/image.png?ex=679c967a&is=679b44fa&hm=543976e348eba65e8f406e42ba2cc92db66ff74d7dccb6520ba7fca10bbaee50&

Haven't played much with the delivery API, but as for this question: > If you have a content picker property, how easy is it to "update" other fields on the same element with data based on the item picked? It is pretty easy in v14+ and in earlier versions I wouldn't bother

By the "extend" property, do you mean the "expand" API parameter?

Yes, I do, thanks! Updated

You can add your own content to the Delivery API index by implementing an

IContentIndexHandler

Hi @Jemayn, What approach would you use for that?

I'd need to play with it myself tbh, was just something that sprung to mind

What version is it? 🙂

v14

Not Extending the Delivery API but we made a Text and an Image Fallback property editor for similar scenarios in 13 - I would have thought this would be even easier in 14+ https://github.com/wholething/wholething-fallback-text-property

I've considered both front-end and back-end solutions. On the back-end for example, modifying the PropertyValueConverter to store extra data in the db - but that really only adjusts the value in that field rather than adjusting adjacent fields on the same document.

Do you need to have the additional fields stored in the DB? Can they not just be additional fields in the index (that's why I suggested IContentIndexHandler)

From within a custom property editor you can listen to changes to other editors via the UMB_PROPERTY_DATASET_CONTEXT, and get their values. Now that I think about it you want to go the other way, not sure how to best go about that

Following to see how you can store data in the db using the Delivery API. Is there two way databinding?

Lee talks about that here: https://discord.com/channels/869656431308189746/1317834360669339739/1318179758583971860

PropertyValueConverters are hit after the database value so wouldn't work to save additional data in the db. It goes db value -> PropertyValueConverter -> Typed model for FE

Perfect! (I actually need that for something else too so that's great!)

Let us know how you get on 🙂

This really is a View/ViewModel concern - do this wherever you're consuming the API, it'll be trivially easy and architecturally correct.

Yeah, I know. I was trying to avoid spamming the delivery api. It also means that my code to "get" the data from the delivery api needs to be much more complex as it needs to iterate through each of the blocks and request more data from the api FIRST as part of the retrieval process (NextJS static build), so that the whole page's static data can be built up. Then we have to do similar logic again during the render step to get the right components. I know it's do-able - just annoying. Oh well. sigh

I don't know enough about NextJS to give any specific help, but in terms of avoiding fetching the same content over and over again with the delivery API we just popped a cache in our client. There is an alternative approach, that's been alluded to above with changes to the PVC or a fallback editor, and that's to make it a proper content model concern - i.e. handle it entirely the other side of the Content Delivery API. I've done exactly this, and done it a few different ways over the years. My favourite approach is a custom property editor, that pulls values through based on the picked content from another property. You can choose to do this readonly or with a "fallback" approach (IME, when editors see the values pulled from content they realise "actually, we should call it this"). The benefit of this approach is that your actual content's C#/TypeScript interface can be the same for either type (in fact, if using a fallback approach you can use a single doctype).