Coupling of default SuperEditor to SingleColumnDocumentLayout and CommonOps (and how to get around it properly)

[JostSchenck]

I encounter difficulties creating my own editor using the default SuperEditor as a basis; I get the impression that it is very tightly coupled to certain classes like SingleColumnDocumentLayout as well as CommonOps that make it hard (at least to me) to replace or extend their functionalities without rewriting (and mostly copying) a lot of the default SuperEditor's functionality. I wonder if I maybe misunderstand the way this toolkit should be used.

My use case: I'm using super_editor to create an outline editor like experience -- like dynalist or workflowy, with paragraphs and their headings being indented and a tree structure being honored while editing; from outliners "folding" (collapsing and expanding) of nodes in the tree is expected. To realise this, the best way I could think of was by implementing my own DocumentLayout, which is very similar to SingleColumnDocumentLayout, but organizes components in a tree of folding widgets according to the structure of the document. However, I can't use my own, very similar DocumentLayout-implementation if I don't either write my own complete editor widget instead of the default SuperEditor, or fork super_editor, adding a parameter to it which takes a builder function for a document layout (idea by @jmatth in #1129), because SingleColumnDocumentLayout is hardwired.

A problem with similarly tight coupling is with CommonEditorOperations; many operations have to behave slightly dfferent with an outliner type of text editor. In the documentation to CommonEditorOperations, it says:

/// If you implement operations for your editor that are not provided
/// by [CommonEditorOperations], consider implementing those operations
/// as extension methods on top of [CommonEditorOperations] so that the
/// rest of your editor can use those behaviors as if they were
/// implemented within [CommonEditorOperations].

This is something that I just don't get: If I create an extension CommonOpsExtension on CommonEditorOperations, I won't be able to reach members like composer, document or editor, because extensions in Dart just don't allow this. And if I do a class MyCommonOps extends CommonEditorOperations, I won't be able to inject it into SuperEditor, as this is hardwired as well (in _createEditContext ). So again, I either have to roll my own SuperEditor replacement, duplicating a lot of code, or fork.

You guys are so passionate about composition that I am sure I'm missing something obvious. Can you enlighten me on what it is? @matthew-carroll @angelosilvestre @knopp

[matthew-carroll]

Thanks for filing this @JostSchenck

First, I'll confirm that currently SingleColumnDocumentLayout and CommonEditorOperations are tightly coupled to SuperEditor. We have some clients that are thinking about funding the creation of a grid-based layout, which will force us to figure out how to decouple layout from the rest of SuperEditor. As for CommonEditorOperations, I tentatively plan to get rid of that in favor of a collection of EditRequests and EditCommands. When we first created CommonEditorOperations, there was no edit pipeline, so there was no concept of requests or commands. But now we have those. Related to that change, I've already started refactoring code to accept only an Editor, and then grab the Document and DocumentComposer from editor.context. This reduces the number of things that seem to always be passed around everywhere.

Now, to your specific question. I'm not sure what you mean by a "tree". But looking just at your reference to collapsing content, have you looked into creating custom components for that purpose? We have a ticket filed for certain collapsing behavior that I plan to work on, but haven't gotten to it yet. My expectation is that I'll be able to accomplish that with new components (widgets), rather than altering the whole document layout. Have you tried that?

Beyond the collapsing question - can you provide any screenshots that demonstrate what you mean by a tree structure?

PS - Our initial intention was for developers to do two things with this package. In cases where developers have use-cases within a kind of standard set of use-cases, they would use the SuperEditor widget with configuration. For use-cases that fall outside those configuration options, we expected developers to compose their own MyEditor widget to replace SuperEditor. Our hope was that many of the same widgets we use inside of SuperEditor would then be used within MyEditor, along with whatever changes are required by that developer's use-case.

[matthew-carroll]

For the component approach with animation, it depends a lot on whether you can animate individual components, or whether you expect multiple components to animate away as if they're one big component. If they can animate independently, then using custom components as they currently exist should work. If multiple components need to act as one, then that probably would need a custom layout.

I'm currently working on the ability to work with nodes inside of nodes. We tried to avoid this as long as possible because going from a list to a tree makes things a lot more complicated. We managed to meet peoples' needs for a few years, but I think we're now at a point where we need that. Once that's done, the components themselves might support the tree structure you need visually. You'll still need custom components but you'll have the composite base that you need.

I suggest that you let us know as you run into individual difficulties so that we can look at providing building blocks that might not exist yet. Your work might also be a good opportunity for us to expand our documentation website to help others in the future: supereditor.dev

[JostSchenck]

I will do that, thanks a lot!

Regarding the documentation website: On supereditor.dev, I currently get a 404 instead of the documentation for super_editor, because index.jinja links to /super-editor-guides/quickstart instead of https://supereditor.dev/super-editor/guides/quickstart/

[matthew-carroll]

You're getting a 404 at supereditor.dev, or you're getting a 404 when following one of the links on the website?

[JostSchenck]

Sorry, I get it following the link "Get started" under "A Document Editor". The links to "A Document Reader" and "A Better Text Field" work fine.

[JostSchenck]

This one should link to "/super-editor/guides/quickstart" instead of "/super-editor-guides/quickstart" (note the slash instead of the second hyphen. If you first click on the link to eg. SuperReader, the link to SuperEditor in the documentation is right. It's only on supereditor.dev landing page wrong.