Edit-message (2/n): Implement variant of content input without a typing notifier

[chrisbobbe]

The edit-message compose box (#126) shouldn't send typing notifications like the regular compose box does.

(There's actually a different kind of typing notification that we'll want to implement eventually; that's #1350. But that's not for us to do now.)

This PR implements _ContentInput.noTypingNotifier, as prep for implementing the edit-message compose box.

Related: #126

[PIG208]

Thanks for the refactor! This will be helpful for implementing saved snippets as well; left a comment bringing that into the discussion.

[PIG208]

I think ideally destination shouldn't be needed for this variant, but I can't think of a better alternative without making destination nullable in the base class _ContentInput and having null-checks in the mixin. (I think this—having a default constructor that allows all combinations, and factories with set values and assertions—is how some Flutter upstream widgets (e.g.: SwitchListTile) handle this.)

For editing messages, providing a reasonable value for destination might still be convenient for the caller (and will become a requirement when we get to supporting typing notifications for editing).

Saved snippets might need a variant that does not have typing notifier or autocompletion; in that case neither narrow nor destination should be needed from the caller, as there are no reasonable values other than null for them anyway:

  factory _ContentInput.savedSnippet({
    required ComposeBoxController controller,
    required String hintText,
  }) => _ContentInputNoTypingNotifier._(
    narrow: null,
    destination: null,
    controller: controller,
    hintText: hintText,
  );

[PIG208]

Another approach would be dropping the mixin, moving the typing notifier logic to _ContentInputStateWithTypingNotifier, and moving the destination field to _ContentInputWithTypingNotifier. However, that won't help if we need the mixin in the future.

[chrisbobbe]

Another approach would be dropping the mixin, moving the typing notifier logic to _ContentInputStateWithTypingNotifier, and moving the destination field to _ContentInputWithTypingNotifier. However, that won't help if we need the mixin in the future.

Interesting! I'll push some wip commits trying this out.

[chrisbobbe]

Thanks for the review! I've pushed some NOMERGE commits with a way to have _ContentInputNoTypingNotifier without destination, following the direction you mentioned in #1431 (comment). It preserves the property that the build method is shared among the with- and without-typing-notifier variants.

[PIG208]

Thanks! This change LGTM. I guess destination might need dartdoc highlighting its relationship with typing notifications.

[PIG208]

nit: remove extra newline