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

[chrisbobbe]

Thanks for the review! Revision pushed, squashing in those commits.

[PIG208]

Thanks! This LGTM.

[gnprice]

Thanks!

One initial comment below, but then zooming out: this inheritance-based setup feels kind of complicated. I think we can split out the typing-notifier logic in a more idiomatic Flutter way by making it a separate widget:

-    return _ContentInput(
-      narrow: narrow,
+    return _TypingNotifier(
       destination: narrow,
       controller: controller,
-      hintText: _hintText(context));
+      child: _ContentInput(
+        narrow: narrow,
+        controller: controller,
+        hintText: _hintText(context)));

So what this PR revision calls _ContentInput.noTypingNotifier would be just _ContentInput. Does that seem like it would also meet the needs of your later changes?

I've just pushed to the PR branch some additional commits that make that change:
921538f wip nfc separate _TypingNotifier widget
1c69a68 wip nfc simplify inheritance back out
4c0369f wip nfc swap order
8805d48 compose [nfc]: Make _ContentInput stateless

I think the first three are probably best squashed into the main commit. PTAL.

[gnprice]

nit: handy shorthand:

Suggested change

	}) => _ContentInputWithTypingNotifier._(
	narrow: narrow,
	destination: destination,
	controller: controller,
	hintText: hintText,
	);
	}) = _ContentInputWithTypingNotifier._;

[chrisbobbe]

That's great, thanks for the suggestion and those commits! That should work well; revision pushed, PTAL. 🙂

[gnprice]

Thanks, looks good. Added a Co-authored-by, and merging.

[chrisbobbe]

Indeed, thanks again!