Symbols would be the ideal placeholder for plugins to set up parameters (in pluginData) for later customization in symbol instances, but, once again, the edit context ruins it for normal use. (You have to drill into the symbol instance to make any modifications.)
I realize the the edit context has large architectural issues, but I would ask you (the Adobe XD plugin team/advocates) to bring up to the XD architects the fact that the edit context is currently wildly over-constraining plugins.
E.g., the most common thing for a data publishing plugin would be to mark a given mask group’s contained shape, and later filling in (when the mask group’s shape is no longer directly selected) “from above” on user request.
Same for a symbol instance, where a plugin would like to make the kinds of changes permitted to a user directly-selecting subparts.
Same for a repeat group, where a plugin building say, charts/graphs, would need to actually modify the shapes involved, not just fill in text or graphics.
I would hope the plugin community would upvote this hugely, so the XD architects could see that this is something long-term that should be solved. Perhaps something of a “user revolt” is needed.
I second this and just want to add another consideration that I think speaks to the core of what XD is supposed to be about.
Unfortunately, the current edit context makes components and repeat grids almost entirely unable to exist at the same time. A repeat grid filled with component cannot, for example, be populated with a DataSeries, leaving a user to choose between repeat grids or components.
Since XD’s long-term goal is to be a design systems tool (which is great!), this limitation isn’t just a small quirk or missing feature.
My plugin has a linter component and it lists problematic elements in the panel. When the designer clicks on one of the elements, I want to set focus (selection) on that element so the designer can fix the error.
Currently this works only if the designer clicks on an Artboard root first. But if they are not, then I show a message asking them to do so. Here’s a picture:
The Edit Context restriction makes this feature almost impractical. This is because the restriction kicks in repeatedly: say the designer focuses on an artboard, and then clicks on a lint error. The plugin would then shift the document’s selection to the element. However, the designer will have to select an artboard root again before they can continue fixing the next error.
The reason for Edit Context, as I understand it, is to prevent plugins from:
damaging the entire document through erroneous operations
making changes not intended by the designer
For the first requirement, a more flexible solution might be to make it safe and easy to revert all changes made by the last plugin invocation. For this, we could use some kind of changeset or transaction_session API so XD can ensure atomic undo for all plugin operations.
The second requirement is important, and the edit context helps there because it localizes all possible changes to the current selection. This makes the changes immediately apparent to the designer.
However, it by definition prevents the creation of any whole-document plugin. This is quite limiting because whole-document operations could yield some of the most useful design automations.
So instead of edit context restrictions, we could discourage unpredictable plugins by proactively informing designers about plugin quality. A way for designers to see and leave bug reports, review comments, and ratings right inside XD could help here…
