Search bar that can offer suggestions and has a definite search result

[jonathanlukas]

Is your feature request related to a problem? Please describe

Describe the solution you'd like

A search bar where I can enter text that displays suggestions when starting to type. Then, when selecting a suggestion, it tells me that I have a definite result.

Describe alternatives you've considered

An alternative would be to split up the functionality in a non-reactive search bar and a button. Also here, I would pick one of the presented suggestions and have a definite result

Additional context

Context is, that form-js could be used by Citizen developers to create forms with ease (it does actually). Sometimes, the requirement is to find a specific business object (a customer, an article, ...) and fill a form related to the context of this business object. To enable a simple finding of business objects, a search bar seems to be a good solution.

Important is here, that I do not want to add technical context like search endpoint and other stuff to the field description. Instead, I would just like to enter a string that defines this context. In the form definition, I do not care about the actual implementation of the search functionality.

[nikku]

Thanks for opening this issue.

I do believe that auto-complete / search dynamically populating fields based on remote queries are something we shall look into, some day, maybe. Related to https://github.com/bpmn-io/form-js/issues/198.

To better understand the issue at hand, can you clarify this:

Important is here, that I do not want to add technical context like search endpoint and other stuff to the field description.

How do you envision to implement the look-up, and why? I do see two options:

• Emit an event on search that is being picked up by whoever embeds the form
• Encode the remote call into the form configuration, meaning that you can, without big configuration, embed the form anywhere.

[jonathanlukas]

Hello Nikku, I can clarify this:

Both ideas are good, whereas I think the greatest flexibility would appear for option 1. I imagine this to work similar to the emit of the submit button for example.

But we should not forget about option 2 as well. This portability can be very useful, especially in simple use cases (where a simple GET or POST request without too many further information would be enough. We could prepare this (would come in handy for PoCs with a custom tasklist) For real world use cases, this will not work as API requests can be more complex and depend a lot on the use case. I am thinking of auth or other custom headers, custom bodies or encoding/decoding of information. Having a property panel or a json object for this in place would exceed the scope of this feature I think.

[nikku]

CC @ingorichtsmeier