Edit-message (1/n): Refactor compose-box banner logic

[chrisbobbe]

These commits help get the code ready to implement the blue "Edit message" banner, with the "Cancel" and "Save" buttons; see Figma:

https://www.figma.com/design/1JTNtYo9memgW7vV6d0ygq/Zulip-Mobile?node-id=3988-38201&m=dev

The most interesting change is to extract a base class _Banner out of _ErrorBanner:

We'll make a new subclass with a name like _EditMessageBanner for #126; here's a rough sketch of what that'll look like:

class _EditMessageBanner extends _Banner { const _EditMessageBanner(); @override String getLabel(ZulipLocalizations zulipLocalizations) => zulipLocalizations.composeBoxBannerLabelEditMessage; @override Color getLabelColor(DesignVariables designVariables) => designVariables.bannerTextIntInfo; @override Color getBackgroundColor(DesignVariables designVariables) => designVariables.bannerBgIntInfo; @override Widget? buildTrailing(context) { return Row(mainAxisSize: MainAxisSize.min, spacing: 8, children: [ ZulipWebUiKitButton(label: 'Cancel', onPressed: () {}), ZulipWebUiKitButton(label: 'Save', attention: ZulipWebUiKitButtonAttention.high, onPressed: () {}), ]); } }

Related: #126

[PIG208]

Thanks! Left a comment; this otherwise LGTM.

[PIG208]

I can see how this is needed for _EditMessageBanner to just be able to override getLabel. What's the drawback of having an API similar to Flutter widgets like Container and make _ErrorBanner and _EditMessageBanner direct subclasses of StatelessWidget? For example:

class _EditMessageBanner extends StatelessWidget { const _EditMessageBanner(); @override Widget build(BuildContext context) { final zulipLocalizations = ZulipLocalizations.of(context); final designVariables = DesignVariables.of(context); final trailing = Row( // … ); return _Banner( label: zulipLocalizations.errorDialogTitle, labelColor: designVariables.btnLabelAttMediumIntDanger, backgroundColor: designVariables.bannerBgIntDanger, trailing: trailing); } }

Maybe keeping _Banner as an abstract base class is needed for code structuring reasons/later changes?

[chrisbobbe]

I think the idea was just to have one fewer widget in the widget tree.

[gnprice]

That alternate API looks like a good one to me. Maybe we'll refactor to it later.

I think an extra widget in the tree isn't a big deal. The style Flutter goes for in general is that widgets are cheap; there are lots of widgets; and they're configured mostly by composition (like in the example code above), rather than by inheritance.

[gnprice]

Thanks to you both! Looks good; merged.