Ideas for future simplification of document processing and API

[Jaifroid]

In working on #680, I've stumbled across certain possibilities that could reduce the amount of pre-processing of elements that we currently do in jQuery mode. I'm recording these here before I forget them, as possible ideas for future simplification.

• No need to attach event listeners to every ZIM link in the document. Instead, a single click event listener can be added to the document, and when it fires we check the event.target. The target will contain the innermost element that was clicked, as opposed to the event.currentTarget which would be element to which the event listener was attached. This seems more efficient to me, and would be a relatively small change at code level.
• The second idea is to generalize the use of Window.postmessage(), which we currently use with the Service Worker, to communicate with the iframe and/or any opened windows or tabs. It might be possible to end up with a unified API for jQuery and Service Worker code, as regards data requests from the article window and dispatching a response from the back-end to it. It would be necessary to add a controlling script to article.html which would act as a layer to request data from the back-end and to inject received data into the document. That script would do some of the processing of the document we currently do with parsing anchors and images. Of course this would only emulate fetch requests, it could never actually trap all the fetch requests in the way that the Service Worker does. A side effect of this is that we would eliminate the CORS issues we have with the iframe if running from the file:// protocol (though this is not particularly important given the existence of extensions).

[mossroy]

A generic event listener might be a good idea, and might speed up some page loading.

About the second idea, I'm not sure I understand.
I suppose the controlling script of article.html would parse the DOM (like displayArticleContentInIframe currently does) but, instead of reading directly the content through selectedArchive.* function calls, it would do a postmessage() instead, and the message could be handled by the same functions used by SW mode?
That might work, but I don't really see the pros of this technique, except to workaround the CORS issues.
Except maybe that it might allow to move most of the jQuery-only code in a separate file? (that might be interesting to clean up the code)

[Jaifroid]

Yes, I think the main advantage of this would be universalizing and simplifying the API for requesting data from the app and the backend. A bit like abstracting a pseudo-Fetch interface for the window containing the document and how it requests data. You're right that the practical outcome for us would in effect be code cleanup: the code is currently a bit schizophrenic, with two different and quite complicated code pathways to get to the same end result (from the user's perspective). I don't know how easy it would be to achieve, but it would be neat if it's possible.