Since I’ve seen a lot of developers struggling with presenting modals inside plugins, I’m excited to announce that I just released the first pre-release (!) version of my xd-dialog-helper on GitHub (https://github.com/pklaschka/xd-dialog-helper) and npm (https://www.npmjs.com/package/xd-dialog-helper). While I’m still in the process of writing the documentation (and refining some rougher edges here and there), it is already functional and allows to easily show simple to medium-complex dialogs to ask for a user’s input. You only need to pass the asynchronous function an array of the information that should get asked (including the type of input as well as some more parameters – depending on the type) and the returned Promise will then resolve with the results in a key-value-pair object (or reject if the user cancels the dialog).
As I’ve stated, I’ll still be fixing some minor issues in the next few days (and complete the documentation), but I just wanted to inform you that this is now officially released and ready to use (as all my open-source-stuff, it is MIT-Licensed). There’s also a sample plugin included in the repo to help you get started while the documentation is still a bit sparse. Depending on whether your plugin is configured to support npm packages, it is as simple as either installing it via npm or copying the dialog-helper.js file which can be found on https://github.com/pklaschka/xd-dialog-helper/releases into your plugin…
If you find any issues, please feel free to open an issue on GitHub so I can get this to be rock-solid as fast as possible.
With the library, asking a user for some simple text input is as easy as writing
const DialogHelper = require('xd-dialog-helper');
let results = await DialogHelper.showDialog('myDialog', 'My Dialog\'s title',
[
{
type: DialogHelper.TEXT_INPUT,
id: 'txtInput',
label: 'Some text input'
}
]
);
console.log(results.txtInput); // The value the user entered in the text field
(granted: for this simple input, that looks like a lot of code, but the fact that this automatically resolves your inputs, does all the dialog boilerplate stuff for you and allows many different types of elements (text, sliders, etc.) as just another element of the array similar to the one of the text field really makes dealing with dialogs – at least to me – a lot easier)
While it’s still WIP (and there indeed is progress, I have published a new version on npm and GitHub earlier today), I’ve gotten a huge junk of the docs for the xd-dialog-helper library done today (see https://github.com/pklaschka/xd-dialog-helper/wiki). What’s especially important is that I’ve finished a TL;DR section for developers who already know a bit about developing plugins for Adobe XD so you can already take a look at the library. You can find the TL;DR section here. For a more comprehensive guide, you can also refer to my more detailed explanation, but you’ll need to bring a bit of time to work through the section since I didn’t get to shortening it, yet …
I’m actually currently creating a WYSIWYG-tool for the library (making it even more “prototyping-friendly” and since it’s able to generate the relevant code, you can actually just create your dialogs, copy and paste the code and await the dialog’s results) because I wanted to try out VueJS and thought it could be fun and interesting to create something like this (and thanks to the spectrum-css CSS design system/ component library by Adobe, it’s actually quite easy to do ):
@kerrishotts Thank you very much – it’s a pleasure.
BTW: I’ve now released a Beta version on GitHub and am hosting the editor (completely free for charge with no ads, data collection or anything else) on https://xd-dialog-helper.pabloklaschka.de/. After opening the site the first time, it also works when you’re offline (due to some – thanks to VueJS – automated magic with service workers)
The only breaking change is that HTML-IDs of elements (content elements as well as the ok and cancel buttons) are now prefixed with the dialog id (passed in DialogHelper.showDialog(...)) so instead of {element-id}, it’s now {dialog-id}-{element-id} (to avoid conflicts with the IDs in successively opened dialogs).
(other than that, I’ve only added Unit tests as well as CI to ensure quality – and maybe get a better rank in the npm search results )
You can download the new release now from GitHub as well as update it via npm with npm i xd-dialog-helper@latest.
Thought @pklaschka was online that time, thus informed him. With good luck, he was and he fixed it immediately. The PR (which was not possible at that time) would have taken extra few seconds for him to go with.
There were two major updates in the last few hours (fixing issues with falsy values like 0, correct behavior when a dialog gets submitted by pressing enter on macOS as well as an easy way to get validation of a dialog disabling the ok button if anything isn’t valid).
Therefore, if you’re using the library, I’d suggest downloading the new version (may that be via npm or GitHub). Since there also weren’t any potentially breaking changes, the update “won’t hurt”
PS: Credits for reporting those issues to me go to @johannes, thank you for that
@NickP Thank you. Unfortunately, it is currently not possible to add buttons to the dialog (since it doesn’t really follow the “form” pattern of the dialog being a prompt for the user to enter further information with every input getting handled by the library). However, more advanced functionality (including buttons, custom elements and much more that goes into this direction is high on the list and will get added when v1.0 of the library is finished, which should hopefully be realtively soon).
For now, I’m still working on a few rough edges with the basic implementation and am trying to get it to be stable as soon as possible. After that, buttons will probably be the first thing that I’ll add…
It fixes a lot of issues and includes a few more features (like programmatically closing the dialog inside the onBeforeShow() callback to close the dialog on custom events). Unfortunately, this has also led to one breaking change (which isn’t evadable since it’s getting closer and closer to v1.0 meaning there have to be a few breaking changes I don’t want to make after v1.0). However, they should be quite easy to adjust to (and I think they won’t even affect many of you, so don’t get too scared .
…
):
)
(haha – no, those assignments are important too…)
)