Creating modal dialogs is so hard

Why the documentation on creating modal dialogs is so hard to understand. The example given seem to not take a developer anywere. There is not a clear path about how to do a modal from start to finish afaik. :frowning:

Making an alert is so thoroughly described, but Dialogs not.

What I mean is if i’m having a command say:

function myCommmand() {
// my code here

which code and where exactly do I put it so the dialog (prompt) will fire as soon as I invoke my main commnand?

So, please make it more clear. Thanks!

1 Like

May I ask which aspect is unclear? It is some standard JavaScript stuff (creating the DOM elements you need) and together with the section, I haven’t found anything to be unclear.

For more complete examples, there are the samples available at, but dialogs come in many “shapes” (some more complex, some more minimalistic) and I don’t think there’s a “one-for-all” solution they could show in the documentation (this – really – is the developer’s decision how to show the dialog: Do it with React? Create an own helper for that? Somethng completely different :wink:).

The alerts could be easily shown since they use the helper library making it a simple function call, but since dialogs are just standard DOM-Manipulation (with all differences already getting described in the documentation), I’d be interested to know what kind of documentation you’d like. For now, is the most minimalistic example for showing a dialog and should help you get started…

Hope this helps,

1 Like

thanks @pklaschka,

so for example here it gives me the code but I don’t know how to invoke it in a real plugin situation, basically the user would not know what to do with it:

1 Like

Correct me if I’m wrong, but that can be seen in the samples (and the information that this is just a plain old HTML dialog element that can be invoked by dialog.showModal(), which returns a Promise (see e.g., is pretty much all the information one needs). After all, this is a reference, and the samples serve as examples to put those things into a real context.

Since this is meant for people already familiar with HTML, CSS, and JavaScript, I’d argue that that’s all the information someone with that expertise needs (and everything on top of that would – in my opinion – clutter up the docs). Don’t get me wrong here, I’m not saying that you’re wrong (the docs are a bit shallow here), but I would argue (and for the sake of making the docs better like to state this point of view), that that’s the way this should be (providing the info people need, serving examples in the samples and requiring some Frontend-Skills that can be acquired elsewhere so the docs can stay as lean and easy to read as they are) :wink:.

1 Like

@pklaschka Alright, I understand now :slight_smile:
Finally I accomplished what I needed to do, after a very long trials and errors, but still I did not make all the features that the plugin needs to be for a better experience, but I need to familiarize myself more with Promises and async await since I was not accustomed with Dialogs in my website development personal history.

1 Like

There is nothing more fulfilling than the knowledge that one has gotten something to work after trying hard :wink: – congratulations. I’m glad you got it working.

Happy coding!


@pklaschka is there a way to make a prompt remember last input typed in the box?

Not an easy one, I’m afraid. I did something like this for my plugins, but you’ll have to use the file system APIs, create a settings file in the plugin settings folder, store the input when the “Apply distance” button gets pressed and retrieve them when you show the modal.

I have some code for that (making it much easier), though. Therefore, if you can wait until tomorrow, I can share this code on GitHub (I wanted to make it open source, anyway, so this is a good excuse for me to take the time to do it :wink:) so it would be much easier and you wouldn’t have to reimplement this (more or less cumbersome) system (checking if the settings file already exists etc.) yourself.



I just found out that Frame Maker plugin remembers user’s last input. Very cool plugin.
I’ll wait until tomorrow, thanks!
I already tryied your plugins without even knowing. I like them a lot :wink:

1 Like

Hi @pklaschka, @aldobsom, thank you for using Frame Maker.

do you mean remembering inserted data after reloading plugins? usually they already keep inputs unless you reload them.


for example this code doesn’t work like this:

I made it work by having the getDialog() function to only “return dialog;” not “return dialog.showModal();”, and add this at the end:

function menuCommand() {
    //  attach the dialog to the body and show it
    .then(result => {
        // handle dialog result
        // if canceled by ESC, will be "reasonCanceled"

//  this file is deliberately written in low level document.appendChild format.
module.exports = {
    commands: {
And here it says:

You can listen for the default gesture (typically [ENTER]) by registering for the submit event on the form :

function onsubmit() {
form.onsubmit = onsubmit;

BUT where to put this code in the code of the dialog?

You would need to get the form element (e.g. assign it an id <form method="dialog" id="myForm">, get a reference to it in your code (document.getElementById('myForm')) and then, you could use this code. I’d also suggest returning a new Promise which you manually resolve when onsubmit() gets called instead of showModal() – this allows you to get all your code in there (you could – for example – resolve this with an object containing options a user has selected and use the result you await elsewhere to do what your plugin should do).

1 Like

@pklaschka Thanks Pablo, apparently I’m too unqualified for this kind of stuff :frowning:
I barely understand how these even work :confused:
I wish there were better example with a more complex scenario.

1 Like

@aldobsom You’ll get the hang of it :wink: . With this part, though, I agree 100% (after looking at it again with this specific question in mind) that the documentation is quite bad (and not very precise) in this area. I remember some earlier version which was much clearer on this (I like bare-bones docs, as stated before, but snippets where its unclear where they’d belong are something different :wink:) .

@kerrishotts I have to agree with @aldobsom that this is more than imprecise – there are some code snippets where it’s unclear where they would belong (actually, they can’t be easily incorporated into the very few code examples provided by the docs – e.g., into It might be wise to give some less bare-bones example code here since it’s difficult for new users to understand (more similar to the way it was during the Beta-Docs, showing a “full” example code section including dismissal, creating and showing a dialog)…


@aldobsom In the meantime, I digged around in the docs repo and looked through the older commits (as I stated: I found the docs on this to have been more comprehensible before and since these commits are publicly available on GitHub, I guess my NDA doesn’t apply to that :wink:), and here’s a version from a while back:

It might not be up-to-date, but it might help you a bit (it’s the “original” docs with which I have learned it during the Beta, so it’s at least possible to learn it with that :wink:)

Hope this helps,
Happy coding,

1 Like

While I’m still working on the documentation of it, here is a link to the repo of my ‘storage helper’ (I’m also working on a small example for using it to have default values in inputs):

Hope this helps,


We’re working on more docs, so things should improve on that front. I thought there was a complete example in the docs, but took another look and there isn’t. Apologies!

That said, the UI is going to be the most difficult piece to build from scratch. There are some helper methods in the Plugin Toolkit repo ( that can simplify some parts of it, and maybe there’s a way we can extend those helper methods to cover some of the more complex bits as well. The setup/teardown aspects can be really tedious and easy to get wrong – and ultimately they are boilerplate, so there may be ways to simplify with abstraction.

Ideas of course, are welcome. More tutorials are going to get added as well, which should help (the advanced concepts section is more about what’s available, and less about the “how”, where as tutorials are intended to show step-by-step how to get something going.)

Anyway – off to lunch, but planning on doing some writing on the docs today. :slight_smile:


Hi, @kerrishotts, @pklaschka, @aldobsom

any news about keeping input data?
@aldobsom I see you used the template literals syntax.
You may try the document.creatElement() variation, just to see if it will solve.

Sincerly, I don’t know if such a change could be the right solution.


I think I saw something on the docs describing this, but I can’t seem to find it anymore :confused:

@kerrishotts I thought there was a complete example in the docs, but took another look and there isn’t. Apologies!
By complex I hope you mean “fully explained” example that just works when copypaste :slight_smile:


I cannot reproduce what you say. I wish there was some code somewhere to read it :slight_smile:

And no matter where I put the code below




always gives me: null or undefined. I dont’t know what to do with it :frowning:

source here: