Skip to content

Vendor Diva.js v7 alongside v6 with a runtime version switch - #970

Open
etosphere wants to merge 1 commit into
diva/1-adapterfrom
diva/2-vendor-v7
Open

Vendor Diva.js v7 alongside v6 with a runtime version switch#970
etosphere wants to merge 1 commit into
diva/1-adapterfrom
diva/2-vendor-v7

Conversation

@etosphere

Copy link
Copy Markdown
Contributor

Closes #964.

As Stage 2 of the Diva v6 -> v7 migration (issue #942), this commit
vendors Diva v7.2.2 side-by-side with v6 and wires it into the build,
with a runtime switch so v7 can be tested locally without touching the
v6 path.

DivaAdapter is refactored that delegates to one of two
backends chosen at initialize() time via localStorage.setItem("divaBackend",
"v7"). DivaBackendV6 is the previous DivaAdapter implementation (the v6
version). DivaBackendV7 is a unfinished implementation that only proves
the wiring: OSD 5.0.1 is injected from CDN, the v7 bundle is loaded on
demand via a webpack dynamic import (keeping it out of the main bundle
on the v6 path), and a Diva v7 viewer mounts over the IIIF manifest.
The Cantus-related behaviour (such as events and navigation) is not
implemented yet.

Diva v7's CSS uses unscoped class names that collide with Bootstrap;
gulpfile.mjs now generates a #diva-wrapper-scoped copy from the vendored
source files at build time, and DivaBackendV7 suppresses v7's own global
style injection using v7's own escape hatch. A height fix in styles.scss
ensures v7's flex layout fills the Diva column.

This commit contains only source files; the built bundles under
nginx/static are not regenerated in this commit.

@kyrieb-ekat kyrieb-ekat left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall looks great; just a quick note that DivaBackendV7 is explicitly a stub in this PR (deliberately doesn't emit viewer:loaded, keeping downstream code dormant) — reasonable staging. One thing to note: backend.initialize() can return a rejected promise (loadOpenSeadragon/loadOpenSeadragon script error, or dynamic import('diva7') failure) and nothing in this PR catches it. It's an unhandled rejection until #971 wraps the call in Promise.resolve(...).catch(...). Probably fine since only devs opting into the v7 flag hit this path at this stage, but worth knowing if #970 is ever merged/deployed on its own.

@etosphere

Copy link
Copy Markdown
Contributor Author

Through #970 to #976 the v7 backend is unreachable unless a developer sets localStorage.divaBackend = 'v7'. The default backend stays "v6" until #977. So no intermediate state of main can expose it to users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Vendor Diva.js v7 alongside v6 with a runtime version switch

2 participants