Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SuperEditor][Web][Guides]: Updates guides for version 0.3.0 (#2429) #2430

Open
wants to merge 12 commits into
base: main
Choose a base branch
from
2 changes: 2 additions & 0 deletions doc/website/source/super-editor/guides/_data.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,8 @@ layout: layouts/docs_page.jinja

base_path: super-editor/guides/

super_editor_version: "^0.3.0"

navigation:
show_contributors: false

Expand Down
18 changes: 16 additions & 2 deletions doc/website/source/super-editor/guides/document-from-markdown.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,13 +17,27 @@ dependencies:
De-serialize a Markdown `String` with the supplied top-level function.

```dart
const markdown = '''
# Header
This is a _Super_ Editor!
''';

final document = deserializeMarkdownToDocument(markdown);
```

The de-serialized document is a `MutableDocument`. Check other guides to find out how to use it.
The de-serialized document is a `MutableDocument`. Add it to your `Editor` similarly to how you did it in the Quickstart guide:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the term "add" is misleading. That makes it sound like some "extra" thing you tack on to an Editor. A Document is a foundational requirement for an Editor.

I think if you want to point people to the Quickstart guide, then we should just do that and not recreate the example code. On the other hand, if you think the example code is needed, then I don't think we need to reference the Quickstart guide. Or at least we don't need to reference it up here above the example.

Here's another version of this part of the guide based on my thinking above:

The de-serialized document is a `MutableDocument`, which can be queried for content, and also mutated to change the content.

A `MutableDocument` is typically used within an `Editor` to implement document editing with user selections, change events, reactions, etc.

    _editor = createDefaultDocumentEditor(
      document: document,
      composer: MutableDocumentComposer(),
    );

To learn more about initializing and displaying a document editor experience, see the [Quickstart Guide](/whatever).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since people presumably just finished reading the Quickstart guide, my thinking is that we don't need to re-explain what a MutableDocument is. I thought having a quick refresher on where to use the document object would be helpful, though.

I take your point about the "add" word, and including a link is a good idea.

But if you would prefer to remove the code block or add the extended explanation, I can do that.


```dart
_editor = createDefaultDocumentEditor(
document: document,
composer: MutableDocumentComposer(),
);
```

Run that, and you'll see the document rendered on the screen.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All code is intended to be run, so instructing the reader to run code doesn't add anything. Additionally, if the user does run the code in the sample, the user won't see anything. So this statement isn't accurate.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if you noticed that I had added the block:

const markdown = '''
# Header
This is a _Super_ Editor!
''';

I did that so that this guide would work more like a tutorial and running the code would produce a visible result. The code in some of the other guides don't run as written. For example, document.deleteNodeAt(2) in the Assemble a Document guide was a code fragment meant to be used as an example and not meant to be run as a part of a tutorial (since 2 would have been out of range). "Run that" is a signal to the user that given code is tutorial style rather than a random snippet, and they should be able to try it out.

Also, the current Quickstart guide that is live now says "Run your app, tap in the editor, and start typing!" I was following this tutorial style pattern.

Is your intention for most of the guides that they should just be code snippets rather than tutorials?


## Serialize Markdown
Serialize a `Document` to a Markdown `String`.
You can also go the other direction. Here's how you would serialize a `Document` to a Markdown `String`:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should avoid implying knowledge about orders of sections. At any time we might choose to re-order sections, add sections, or remove sections. A section is meant to describe an isolated concern, so it shouldn't be difficult to avoid referencing things that come before or after.

In this case, it doesn't look like any additional information was conveyed by the addition of words. If you feel that the existing sentence doesn't provide enough context, then you could elaborate on context. But if the existing sentence actually communicates all relevant info, then it probably doesn't need to change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I misunderstood the original intent in updating the guides from a new user's perspective. I was updating them as if I were working through the guides as a new user reading them in the order they appear in the menu and reading each guide from top to bottom. I see now that that was not your intention.


```dart
final markdown = serializeDocumentToMarkdown(document);
Expand Down
91 changes: 46 additions & 45 deletions doc/website/source/super-editor/guides/quickstart.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,68 +2,69 @@
title: Super Editor Quickstart
contentRenderers: ["jinja", "markdown"]
---

# Super Editor Quickstart
Super Editor comes with sane defaults to help you get started with an editor experience, quickly. These defaults include support for images, list items, blockquotes, and horizontal rules, as well as selection gestures, and various keyboard shortcuts.
Super Editor comes with sane defaults to help you get started quickly with an editor experience. These defaults include support for images, list items, blockquotes, and horizontal rules, as well as selection gestures and various keyboard shortcuts.

Drop in the default editor and start editing.

## Add <code>super_editor</code> to your project
To use <code>super_editor</code>, add a dependency in your <code>pubspec.yaml</code>.
## Add `super_editor` to your project
To use `super_editor`, add a dependency in your `pubspec.yaml`.

```yaml
dependencies:
super_editor: {{ pub.super_editor.version }}
super_editor: {{ super_editor_version }}
```

## Display an editor
A visual editor first requires a logical editor. A logical editor holds an underlying document, which the user edits, and a composer to manage the user's selection.
Super Editor is both the visual editor that users see and interact with, as well as the logical editor that handles those interactions behind the scenes.

Initialize the logical editor.
Start by initializing the logical editor:

```dart
class MyApp extends StatefulWidget {
State<MyApp> createState() => _MyApp();
}
import 'package:flutter/widgets.dart';
import 'package:super_editor/super_editor.dart';

class MyEditorPage extends StatefulWidget {
const MyEditorPage({super.key});

class _MyApp extends State<MyApp> {
late final Editor _editor;
late final MutableDocument _document;
late final MutableDocumentComposer _composer;

void initState() {
super.initState();

_document = MutableDocument.empty();

_composer = MutableDocumentComposer();

_editor = Editor();
}

void dispose() {
_editor.dispose();
_composer.dispose();
_document.dispose();

super.dispose();
}
@override
State<MyEditorPage> createState() => _MyEditorPageState();
}
```

With the logical pieces ready, you can now display a visual editor. Build a <code>SuperEditor</code> widget and return it from your <code>build()</code> method.

```dart
class _MyApp extends State<MyApp> {
// ...

Widget build(BuildContext context) {
return SuperEditor(
editor: _editor,
);
}

class _MyEditorPageState extends State<MyEditorPage> {
late Editor _editor;

@override
void initState() {
super.initState();
_editor = createDefaultDocumentEditor(
suragch marked this conversation as resolved.
Show resolved Hide resolved
document: MutableDocument.empty(),
composer: MutableDocumentComposer(),
);
}

@override
Widget build(BuildContext context) {
return SuperEditor(
editor: _editor,
);
}
}
```

Multiple objects work together to edit documents. A `Document` provides a consistent structure for content within a document. A `DocumentComposer` holds the user's current selection, along with any styles that should be applied to newly typed text. An `Editor` alters the `Document`.

The `Editor` fulfills a number of responsibilities, each of which is configurable. Rather than force every user to fully configure an `Editor`, `super_editor` provides a global factory called `createDefaultDocumentEditor`, which configures an `Editor` with sane defaults. To adjust those defaults, consider copying the implementation of `createDefaultDocumentEditor` and then altering the implementation to meet your needs.

The `SuperEditor` widget creates a user interface for visualizing the `Document`, changing the selection in the `DocumentComposer`, and submitting change requests to the `Editor`. The `SuperEditor` widget is the part that most people think of when they think of "document editing". The `SuperEditor` widget includes many configurable properties, all of which focus on user interactions, e.g., selection and focus policies, gesture interceptors, scroll control, mobile selection handles, and more.

That's all it takes to get started with your very own editor. Run your app, tap in the editor, and start typing!

The next step is configuration. Check out the other guides for more help.
Continue your Super Editor journey with more beginner guides:

- [Document](TODO)
- [DocumentComposer](TODO)
- [Editor](TODO)
- [SuperEditor](TODO)
- TODO: other useful next step guides.
Loading