Is it possible to add root node pluginData from background?

Adobe XD UXP Plugin API
1

I have websocket message handler:

websocket.onmessage = (data) => {
    setRootNodePluginData(data);
};

and setRootNodePluginData function:

function setRootNodePluginData(data) {
    scenegraph.root.pluginData = {data: data};
}

but when message received i’ve got error about edit context:
Plugin Error: Plugin <PLUGIN_ID> is not permitted to make changes from the background. Use editDocument() for panel UI handlers, or return a Promise to extend an edit operation asynchronously.

Is there any way to edit scenegraph from background? Maybe some workarounds?

1 Like
2

None that I’m aware of. The only “workaround” (and it really isn’t one, but just the only option I see of somehow doing this) would be to leave the plugin running in this time, but this would require the user not being able to edit the document during this time.

Maybe, with live collaboration now being a thing in XD, it would be possible to leave one computer running the plugin with another one doing the changes to the document, but that’s really just an option in some hacky use-case where you yourself are the plugin’s user (and it’s probably required to have two Adobe accounts for that to work). Since I believe we can both agree that this is far from practical in a real scenario, I tend to believe you’re out of luck there. Of course, it’s possible that I just don’t know of a workaround, if there is one, but for a first, quick response, I’d say it’s currently not possible.

1 Like
3

Thanks for the answer. I think we can request a feature :grinning: It would be great to have ability to store some common pluginData (on root node) outside edit context.

1 Like
4

I think i found some kind of solution. Need to wait for promise that resolved through stored resolve function :grinning: The idea is:

var resolveFunction;

...
websocket.onmessage((message) => {
    resolveFunction();    
});
...

function processCommand() {
    return new Promise((resolve, reject) => {
        // some logic
        resolveFunction = () => { 
            // edit root node plugin data
            resolve(); 
        };
    });
}

async function someCommand() {
    await processCommand();
}
1 Like
5

Still, this locks editing until the promise is resolved. I tried to debounce a text area using this, once, without success…

cf. Debouncing input events in panels

1 Like
6

Yes, locks. But for my case it’s ok - requests is fast enough to be sync :wink:

1 Like
7

Ok, I’m curious (not saying anything is wrong, just interested in the why :slightly_smiling_face:). Without going into detail, I’d be interested to know why this uses a websocket, then. Are you using some external that you don’t have any control over? Because otherwise, a websocket that basically “resolves” fast enough that the above doesn’t cause problems sounds pretty much like an overly complicated HTTP request to me :rofl:.

1 Like
8

Yes, sounds like http is better for this case, but i need async requests too. I don’t think that xd plugin has ability to deploy http server :grin:

1 Like
9

Ah, ok. Thanks for answering :+1: :slightly_smiling_face:.

@kerrishotts Just out of curiosity (and, as it is potentially interesting for some personal projects of mine regarding automated plugin testing for XD): Could this actually work?

1 Like
10

I’m not sure if that could work or not. IIRC, there were issues in the past wrt plugins & coediting, so you could get some very odd results. Not sure if those are still a thing (@schenglooi, is that still true?)

As for editing the root node’s data – because it’s part of the document (and has to be sync’d with the rest of XD and any attached editors), there’s no way to safely edit this without locking the document. So the promise solution is the correct way to handle things – lock the document until your response comes back.

XD doesn’t currently have the ability to start a server, but it’s something on my wishlist… :slight_smile:

3 Likes
11

Coediting works if you are editing the same document from two devices though it doesn’t have to be two different accounts. Basically you can turn on coediting and share the document to yourself on two different devices. Keep in mind this is still a beta feature so there may will be weirdness still going on. Note that plugins that opens a modal dialog will block all future remote edits until the modal dialog is dismissed. And remote user that has first access to the document may also prevent the other user on a different device from changing the same document, i.e. some changes maybe auto-reverted.

Currently, any edits to the document, including the root node, must be done within editDocument context since it is an undoable change.

3 Likes
12

@kerrishotts @schenglooi thanks for the feedback :wink:

1 Like