Consider how to do polymorphic full-record display

The conclusion from an extensive discussion on , achieved by two falls, two submissions or a knock-out:

• We will retain the convention that every plugin is its own NPM package. (There was virtually unanimous consensus on this.)

• We will retain the convention that every plugin is in its own GitHub module. (There was less consensus on this, but a combination of theoretical arguments and bad experiences in trying to "economise" on number of git repos made it a clear majority in the end.)

• The maintainer of a given UI app module (e.g. ui-inventory) will also be responsible for the corresponding full-record-view plugin module (e.g. ui-plugin-view-inventory).

• The plugin will be used by by its associated app, and by the Codex search (ui-search).

(Please, no-one attempt to re-open the discussion. We've done this to death already.)

The philosophical discussion has moved to .

I will summarise here when it reaches a conclusion.

Yep. Sounds right to me.

I like the idea of linking first and am fine with both the plugin approach or keeping these in stripes*components.

I am keen to avoid importing code directly from apps / stripes-core because it becomes ambiguous what is a public API (or a private one) and may make it impossible to enable app A that depends on a component from app B without also enabling B.

Maybe, but it simplifies dependency management as seen from the "client app" (ui-search in this case) point of view.

Btw, I've seen that you picked up , which is fine. What we have discussed with EBSCO KB team is that showing basic (common) CODEX instance metadata and a link to a specific app would be the first thing we do (so there's a backup for alpha) and then turn our focus on the embedding/plugin approach. No one seems to like having to click to see things like holdings or packages, though, so linking is only a temporary solution.