Transaction meta key naming

1

I’ve enjoyed working with the new transaction.setMeta / transaction.getMeta system for passing plugin-specific data along in the new transaction dispatch setup. In some of the example implementations (in the prosemirror-* repos as well as the demos) it seems like the pattern is to store varyingly-structured data with a plugin-specific key generated by the plugin system (either with Plugin.key or PluginKey). Others of the examples — including the History plugin, as well as Collab — make use of setting a “global” key like addToHistory or rebase, to allow other plugins or logic to work with these keys.

In the case of History, the mechanics of the addToHistory key is well-documented on the website, where you’d plausibly run into it while working with that particular plugin. But the presence of this kind of global key is not part of the spec of the plugin itself, though — as I understand it, any other plugin is free to over-write or use this same key for their own purposes. Certainly addToHistory seems benign on its own, but in an editor use-case with a lot of small purpose-specific plugins, where some behavior is shared between plugins and other behavior should be “scoped” to a given plugin, I’m curious about how best to ensure that individual plugins play nicely together with their meta keys.

I’m not actually sure what form this might take, but I’m drawn to a solution where a plugin exports some kind of function(s) or keys for any behavior it wants other transaction “creators” to re-use. I guess you could call it namespacing, but it could look something like:

const myPluginKey = new PluginKey("myKey");
# ...plugin definition here
export function exemptFromHistory(tr) {
  return tr.setMeta(myPluginKey.key + "addToHistory", false);
}

One other advantage an approach like this affords is the ability to change the contents of the meta value without forcing other plugin consumers to rewrite the calling code. I realize the very real downside to this approach is that it’s more complex! Most plugins are likely to only ever create/react to transactions internal to the plugin, & this pattern wouldn’t really change that. I guess maybe I’m curious more generally to get a better sense of what an idiomatic ProseMirror setMeta / getMeta architecture should look like :slight_smile:

2

That’s what I’m doing with the (recent) closeHistory method in the history plugin, and it’s generally a good idea. But for some kinds of metadata I think it’s valuable to be able to set and read them without adding a dependency on a plugin. For example, I can imagine an alternative implementation of the undo history to also read addToHistory and thus work with existing code.

The danger of such name clashes is, I think, not too great as long as people choose names that aren’t too short/common. I.e. don’t start using "id", and prefer private (PluginKey) names whenever practical.