Abstract chrome.runtime.onMessage

[mkobayashime]

Wrap chrome.runtime.onMessage and provide reasonable types.

[yudukikun5120]

@mkobayashime Could I hear the motivation for wrapping chrome.runtime.onMessage? This wrapping seems to be similar to chrome.storage and I thought this is because of the restrictions of the first parameter (e.g. channel name) (, and this is a common problem for developers who struggle with IPC).

[mkobayashime]

@yudukikun5120
We generally should wrap this kind of external interfaces so that we can deal with any changes/updates to the interface with minimal changes to the codebase (hopefully only on the wrapper layer). Abstraction like this in chrome.storage will help us in migration to MV3 actually.
Additionally, chrome.runtime.onMessage recieves all messages emitted from anywhere, one intended to download report template file and another one intended to open options page. The onMessage listener you added in #416 actually duplicates with existing one (here) listening for clicks of the link for the options page, so we have to pass props like action: 'openOptionsPage' | 'downloadReportTemplate' and detect the intention of the message in onMessage. Using chrome.runtime APIs directly makes it harder to avoid this kind of mistakes.

[yudukikun5120]

@mkobayashime I'm glad to know the intention of the wrapping. I understand it in the context of the namespace of the onMessage and will pass it through the wrapper on the later coding.