Provide an event subscription system for external API consumption

[aeschylus]

There are many, many ways of accomplishing this. The use cases are described in a general way in #1693, and we know of a list of required events in #1865.

One proposal is given in @charbugs ' wiki page, but I want to discuss this more (in the present ticket).

In particular, I would prefer that much of the external subscription facility be provided by some automated means or middleware. Investigating the react/redux community sentiment toward this, I've run across this list of libraries and approaches. Looking through them, I found the first one listed (redux-watch) to be the closest to how I imagined it working.

Redux docs on this topic: https://redux.js.org/faq/store-setup#how-do-i-subscribe-to-only-a-portion-of-the-state-can-i-get-the-dispatched-action-as-part-of-the-subscription

There is still an open question in my mind though about how to broadcast events that don't come from or create state changes, or that happen not to correspond with actions.

[charbugs]

Do you consider "external subscription" a different thing from plugins that intercept actions via reducers?

[aeschylus]

I think so, but I don't think I know exactly how plugins should intercept actions via reducers. In the current plugin system, plugins only receive the updates for props that are passed into the parent into which they inject themselves, not the whole state. However, they can read the state whenever they like, and can inject their own reducers. There is an example of this in the integration tests, though I don't think it's very fleshed out.

How do you imagine the reducer interception working? The plugin system has a lot of room for improvement. Could we create another integration test with a plugin that would require this type of interception?

[charbugs]

1. The problem is, that the current plugin implementation doesn't work correctly (see Plugin implementation doesn't work as intended #2099). So, integration tests may not be meaningfull at this point. We should fix that first.

2. If you inject a custom reducer to the store this reducer can react on each action type that the application dispatches like every other reducer does. (Could it be that the word "intercept" is missleading here? I do not mean: caching the action type and prevent all other reducers from react on them.)

3. So, if subscriptions are different from plugins than we have basically 4 domains of external APIs:

• a) configuration of Mirador as script
• b) configuration of Mirador as react app
• c) subscriptions to events
• d) plugins

Would you agree with that classifications? Are there more?

[aeschylus]

These are the main APIs, but there is more to the details. The reasons for providing these different types of APIs has to do with the community of users. I've provided some context for this here: #1693.

It seems we're touching on these questions more and more this week, which is good. Not sure which of these concerns needs to be tackled first in order to lead to the best outcome.