handleMessage default behaviour leads to superfluous errors

[jryans]

On each side of the widget transport, there are handleMessage functions such as:

    private handleMessage(ev: CustomEvent<IWidgetApiRequest>) {
        const actionEv = new CustomEvent(`action:${ev.detail.action}`, {
            detail: ev.detail,
            cancelable: true,
        });
        this.emit(`action:${ev.detail.action}`, actionEv);
        if (!actionEv.defaultPrevented) {
            switch (ev.detail.action) {
                case WidgetApiToWidgetAction.SupportedApiVersions:
                    return this.replyVersions(<ISupportedVersionsActionRequest>ev.detail);
                case WidgetApiToWidgetAction.Capabilities:
                    return this.handleCapabilities(<ICapabilitiesActionRequest>ev.detail);
                case WidgetApiToWidgetAction.UpdateVisibility:
                    return this.transport.reply(ev.detail, <IWidgetApiRequestEmptyData>{}); // ack to avoid error spam
                case WidgetApiToWidgetAction.NotifyCapabilities:
                    return this.transport.reply(ev.detail, <IWidgetApiRequestEmptyData>{}); // ack to avoid error spam
                default:
                    return this.transport.reply(ev.detail, <IWidgetApiErrorResponseData>{
                        error: {
                            message: "Unknown or unsupported action: " + ev.detail.action,
                        },
                    });
            }
        }
    }

At the moment, the library seems setup (based on the guide on the repo home page) to require widget developers to call ev.preventDefault() on anything they listen to and craft their own reply, even when it's effectively a one way notification and an empty reply is just fine.

As shown above a few random notification-like actions (UpdateVisibility, NotifyCapabilities) are auto-replied, while all others (e.g. SendEvent) default to sending back an error, even though the data was emitted and probably processed by the widget anyway.

I would suggest flipping around the default behaviour to sending empty data and dropping the error path. After all, the data has been emitted already, and (most likely) processed.