Prompt dialog should consume a <datalist> element

[aeisenberg]

• I'm submitting a ... [x ] feature request

• What is the current behavior? The prompt dialog does not allow clients to provide a datalist element to specify valid options. However, this would be a very useful feature and most likely not difficult to implement.

• What is the motivation / use case for changing the behavior?

This is a useful thing when there are a small number of valid options for a prompt.

• Browser: [all]

If you think this would be a useful feature, please let me know and I will submit a PR. I'll probably implement this anyway since this is useful for our own project, but I would like to contribute this back.

[aeisenberg]

So, PR #351 is working for me and we are going to start using it in our project in a production build. I'm happy to work on making this more complete by including documentation and updating the demo code, but I would like some feedback first to make sure that this feature could possibly be included in the project.

[shlomiassaf]

@aeisenberg Thanks!

Seen your PR #351 but I believe it's not something that the library should support as it is too specific.

Here's my 2 cents: A component library which is distributed publicly need to maintain a balance between it's feature set and its size/complexity/api (all relate one another)

So you'r specific requirement is valid but specific for a use case.

Next, some other developer would want multiple inputs, a radio button, etc...

I provided minimal support for alert, prompt and confirm just because they are common, the library can exist without them... it will just require custom implementation using custom components but not using a custom build

The library itself has no modals, only the plugins add the actual behaviour which means it's a highly extensible library...

You can easily create what you want without a custom build just by creating a custom preset (the demos show how to) and/or a custom component. You can even inherit the existing implementation and extend that.

If you wish to stay with a custom build or not it's up to you, I would recommend using the original build and adding your custom preset/component.

Thanks, Shlomi.

[aeisenberg]

Thanks for taking a look at the PR. It's your project and you certainly have the right to determine what its features should and should not be.

I would like to move away from our custom build, but I can't find in the documentation how to build a preset.

[shlomiassaf]

It really not about me being the owner, if something makes sense and a lot of people request it I'll do it even if I disagree.

The logical rules I apply here are simple, if something can be done using existing API and its serves a specific use case then it should not get in.

As for documentation, there aren't much. Tried several times to ask for help but not a lot of jumpers :)

You have multiple ways of doing it, just look at how the bootstrap plugin is implemented and do the same.

Assuming your using the bootstrap plugin...

What you need is to inherit the Modal class from the bootstrap plugin and create a provider for it. Then it can be used to open modals.

Add a method to server as your preset and from there just extends the context classes.

Everything you need for the implementation can be found the bootstrap plugin... you just need to alter a bit by inheriting