Webiny v6 Custom Component selectInput component that can make API calls

[lm778]

Is your feature request related to a problem? Please describe.

I am using Webiny V6 with a NextJS front end. A great feature to have is a select input option on custom components that can reference existing CMS models as the options. My example is:

My website has a features list. We have a CMS model listing 25 Features of our product. I have multiple Feature List custom components that I use throughout my website. I would love to be able to just select from my existing Features entries when adding new Feature Custom Components in the website builder.

Describe the feature's behavior.

No response

Describe alternatives you've considered.

No response

[Pavel910]

@lm778 We actually need this ourselves, discussed exactly this last week 😅

Would an entry "id" be enough for you as a value? Or do you need some more complex value?

[lm778]

@Pavel910 Thanks for your quick response. It would be great if it worked the same way the reference fields work in the CMS models. For instance I have a Blog model that I've set up a reference field so I can select a few other related blogs to show in the UI. I think that same setup for the selectInput option on a custom component would be very useful.

[Pavel910]

@lm778 Yes, on the page editor side it will work like the ref field in cms. But the value will be either an entryId or an array of entry ids when loaded in nextjs, so loading of actual entry data will be on you, via the sdk.

[lm778]

@Pavel910 got it. Yeah, I think pushing the loading onto the developer is fine. It would pretty much be making the selectInput props have an async loading option where the developer could specify the endpoint as well as the mapping back to the options format that exists now. I think that would probably be the most flexible. In terms of storing the selected items, it might make sense to allow the developer to specify the object to store as well. that way the api call doesn't need to get run for the page to build with the selected options.

[Pavel910]

@lm778 storing objects creates a lot of issues and implementation complexity:

1. when searching a ref (in the editor), we don't load all the data, only the title field + id.
2. if you decide you need an extra field on the frontend down the line, and you forgot to add it while building the pages, you now have to reselect values and republish pages just to get the new object stored
3. unnecessary bloat of the page record itself + the data becomes stale the moment you change something in the CMS itself.

Having just an id, or an array of ids, gives you all the freedom of fetching the necessary data on the frontend, plus data will never be stale.

We'll probably tackle this in 6.5.0. Next week we're releasing 6.4.0, it's locked for the release, so keep an eye on our releases. I will assign this issue to 6.5.0 milestone, as the initial goal.