Skip to content

[SuperEditor][Adjustment] - Expand usability of HintComponentBuilder #2655

@matthew-carroll

Description

@matthew-carroll

Currently the demo_text_with_hint.dart demo uses a custom HeaderWithHintComponentBuilder(). I tried to replace that with our standard HintComponentBuilder and found that I couldn't match the same functionality.

We should make some changes to both the demo and to HintComponentBuilder so that the demo can use the standard implementation.

Changes to the demo

The demo shows 3 hints, one after the other, followed by a paragraph of text. These 3 hints were shown together to demonstrate at one time that hints can be presented as different header levels and as a normal paragraph. But it doesn't make sense in real usages that hints would follow one after another. To demo this capability, but in a real way, add a demo configuration to the right side of the screen and let the user select from examples with different levels, e.g., "h1", "h2", ..., "p".

In the demo, the first node should display a hint whenever it's blank, even if it's followed by other content. This part of the demo relates to use-cases like Medium blog posts where the first node is always a title, and whenever it's empty, a hint should be down.

Changes to HintComponentBuilder

We should offer both simpler and more complicated configurations for HintComponentBuilder.

Currently HintComponentBuilder only accepts a String for the hint, and only accepts a style function callback for the style. We should support all of the following configurations.

  • The hint can be a String or an AttributedText.
  • The hint style can be a TextStyle or a style callback with signature TextStyle Function(BuildContext, Set<Attribution>, TextStyle baseStyle).
  • The logic for when to display a hint should be configurable via a delegate function. Something like bool Function(BuildContext, Document, ParagraphNode). The existing selection behavior in the HintComponentBuilder should be moved to a static function, which is then used as the default when user's don't provide their own.

When making the above changes, keep the existing constructor and deprecate it. Use various named constructors for other variations.

When making these changes, ensure that the component builder respects the block type of the corresponding node. For example, when showing a hint in a header1 ParagraphNode, ensure that the hint is shown with a header style base, and that the node generally retains header behavior and styles when typing.

Metadata

Metadata

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions