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.
For more complete examples, there are the samples available at https://github.com/AdobeXD/plugin-samples, 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 ).
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, https://github.com/AdobeXD/plugin-samples/tree/master/ui-hello is the most minimalistic example for showing a dialog and should help you get started…
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. https://adobexdplatform.com/plugin-docs/reference/ui/dialogs/showing.html), 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) .
@pklaschka Alright, I understand now
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.
There is nothing more fulfilling than the knowledge that one has gotten something to work after trying hard – congratulations. I’m glad you got it working.
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 ) 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
WORKAROUND:
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
document.body.appendChild(getDialog()).showModal()
.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: {
menuCommand
}
};
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).
@pklaschka Thanks Pablo, apparently I’m too unqualified for this kind of stuff
I barely understand how these even work
I wish there were better example with a more complex scenario.
@aldobsom You’ll get the hang of it . 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 ) .
@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., https://adobexdplatform.com/plugin-docs/reference/ui/dialogs/dismissal.html into https://adobexdplatform.com/plugin-docs/reference/ui/dialogs/#js). 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)…
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 )
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 (https://github.com/AdobeXD/plugin-toolkit) 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.
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
@kerrishottsI 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
).
