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