Clicking on an icon of a custom component (task item) to change its type (open/done)

[siuvoniazzi]

Hi everyone

I created a custom component similar to a list item (ordered/unordered) to represent a task (open/done). Depending on what type a task item is, there's a leading checkbox icon that's unchecked or checked.

Now I can't figure out how to implement the user interaction ,i.e. clicking the checkbox, so that the taskItem type converts from e.g. open to done, or from done to open resp.

So far I've wrapped the leading checkbox in the respective widget with a GestureDetector which works alright for printing anything to console but I'm missing how to convert the taskItem type to a different one.

I suspected I would have to use an extension method on CommonEditorOperations (see here), but it looks like I need access to the EditContext in order to get to the selection and the specific node within the document to change the task item's type. And that's where I hit a wall. As I understand it, in order to stay within the SuperEditor.custom setup, I can't just pass in the EditContext, right?

Can anyone point me in the right direction, how would you go about it?

Cheers

[osaxma]

Hi @siuvoniazzi

I had a similar use case before where the user can click on an image to replace it while preserving the node's data (e.g. index in the document). The main issue was: updating the node's data from the component.

While SuperEditor still doesn't provide any direct approach to the problem, having the BuildContext accessible (through ComponentContext of ComponentBuilder) makes the InheritedWidget approach a viable option. I implemented this approach using the Provider package which is just a sugarcoat for InheritedWidget.

Simply, I wrapped SuperEditor.custom with a Provider for a custom controller, and I accessed that controller inside the ComponentBuilder through the BuildContext.

Here's how the SuperEditor side looks like:

Widget build(BuildContext context) {
  return Provider(
    create: (context) => MyCustomController(editor:  _docEditor, composer: _composer),
    child: SuperEditor.custom(
      editor: _docEditor,
      composer: _composer,
    ),
  );

As you may have noticed above, MyCustomController has both the DocumentEditor and DocumentComposer so it can make changes to the document using commands, and hence it can expose any necessary functionality.

And here's the ComponentBuilder side:

Widget? myCustomComponentBuilder(ComponentContext componentContext) {
  final myCustomNode = componentContext.documentNode;
  if (myCustomNode is! MyCustomNode) return null;
  
  return MyCustomComponent(
    data: myCustomNode.data,
    onTap: () {
     // access the controller
      final myCustomController = Provider.of<MyCustomController>(componentContext.context, listen: false);
     // do what you gotta do
      myCustomController.onTap(........); 
    },
  );
}

Here's a full simplified example:

Screen.Recording.2021-06-16.at.2.06.50.AM.mov

[osaxma]

By the way, I just remembered that you can also do the same without InheritedWidget or Provider. Since DocumentNode is a ChangeNotifier, you can define the CheckBoxNode as follow (for the same example):

class CheckBoxNode extends ParagraphNode {
  CheckBoxNode({
    required String id,
    required AttributedText text,
    bool isChecked = false,
    Map<String, dynamic>? metadata,
  })  : _isChecked = isChecked,
        super(
          id: id,
          text: text,
          metadata: metadata,
        );

  bool _isChecked;
  bool get isChecked => _isChecked;

  void toggle() {
    _isChecked = !isChecked;
    notifyListeners();
  }
}

And Component Builder will become:

Widget? checkBoxBuilder(ComponentContext componentContext) {
  final checkBoxNode = componentContext.documentNode;
  if (checkBoxNode is! CheckBoxNode) {
    return null;
  }

  final isChecked = checkBoxNode.isChecked;

  return CheckBoxComponent(
    textKey: componentContext.componentKey,
    text: checkBoxNode.text,
    styleBuilder: componentContext.extensions[textStylesExtensionKey],
    isChecked: isChecked,
    onClicked: checkBoxNode.toggle,
  );
}

The main reason I avoided this approach in my case was to stick to the command approach (i.e. to have redo/undo support once it lands).

[siuvoniazzi]

Awesome, thanks a lot, for both approaches. I will give this a try!