Copy stringify model to clipboard

[pomek]

It allows casting the model tree to a string that could be used in setModelData function in our tests.

Not sure how often it could be used but when you want to report an issue that occurs in a specified scenario, you could paste your model as an entry point.

[oleq]

I came upon it and I also find it annoying, so I'm gonna give it some real priority.

[oleq]

Our set/get data utils use the editor view and the writer to generate the stringified data structures. For the inspector to do the same, these utils would need to be exposed by the editor first. Otherwise the inspector would need to create a pseudo-editor instance itself (at least the view) for its internal processes which feels like an overkill to me. Plus, I think this internal view instance would need to be of the same version as the editor being stringified for compatibility reasons (if their APIs diverge, it's an instant crash).

Although I totally support the whole idea, TBH, I'm not sure where to start. Maybe the editor could expose these utils somewhere and then the inspector would discover whether they are exposed or not and it would (or would not) allow using them in the UI? WDYT @jodator?

[jodator]

Although I totally support the whole idea, TBH, I'm not sure where to start. Maybe the editor could expose these utils somewhere and then the inspector would discover whether they are exposed or not and it would (or would not) allow using them in the UI? WDYT @jodator?

The idea with exposing somewhere is probably only feasible way to do that because of what you mentioned about compatibility and having and editor instance anyway. 

However, adding this to builds might be overkill.

create a pseudo-editor instance itself

I don't think that is what happens with getData() for view and model utils - at least if I'm looking at this correctly:

https://github.com/ckeditor/ckeditor5/blob/2b91300a98034182d8c5f19f0898928487056803/packages/ckeditor5-engine/src/dev-utils/view.js#L246-L261

At first glance - it doesn't have much external (engine) deps and might be feature proof but that would require some work to check how this would behave.

I see two options for now:

1. Make Insepector detect debug build with exposed view/model stringifiers.
2. Make Inspector include view/model stringifiers (if it would work anyway - duplicated modules error?).

[oleq]

• Make Insepector detect debug build with exposed view/model stringifiers.

We could bring the InspectorIntegration plugin to the editor that exposes some helpers. And these features would be available in the inspector only if it discovered that plugin.

2. Make Inspector include view/model stringifiers (if it would work anyway - duplicated modules error?).

TBH I'd rather avoid duplicating the code. The purpose of this issue is that you can easily select an element in the model, click "stringify" and then copy the output to tests (as an initial data, as an assertion result). If the implementations in the editor and the inspector diverge by a just tiny little bit, the feature is useless.