@jbrowse/app-core 5.0.0-beta.7 → 5.0.0-beta.9

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,78 +0,0 @@
1
- import { jsx as _jsx } from "react/jsx-runtime";
2
- import { openTracks, openViews } from '@jbrowse/core/util/openViews';
3
- import { observer } from 'mobx-react';
4
- function trackLoading(track) {
5
- return track.displays.some(d => d.displayPhase === 'loading');
6
- }
7
- /**
8
- * A view whose init failed (its assembly was never found) stays uninitialized
9
- * for good and paints its error, so like a display's terminal phase it is
10
- * finished, not pending: without this the whole app read `loading` for as long
11
- * as that view was open, and every settle answered false with no reason.
12
- *
13
- * `pendingLaunch` is the third term and the one that was missing. `initialized`
14
- * goes true mid-launch — LGV's flips the moment displayedRegions land, while
15
- * the same apply pass still has the spec's tracks to attach — and `showLoading`
16
- * goes false at the same moment, deliberately, so the reader sees the
17
- * navigated view rather than a spinner while its tracks arrive. That left a
18
- * window, exactly as wide as attaching the tracks, in which the marker said
19
- * `ready` over a session missing everything it had been asked for.
20
- * `whenViewSettled` states the same rule for the callers that await a single
21
- * view, and says why in more detail. Not shared as one predicate: that one
22
- * requires `initialized`, while absent here means not loading, and an adapter
23
- * between the two null rules would read as agreement it does not have.
24
- */
25
- function viewLoading(view) {
26
- const flags = view;
27
- return (flags.error === undefined &&
28
- (flags.showLoading === true ||
29
- flags.initialized === false ||
30
- flags.pendingLaunch !== undefined));
31
- }
32
- /**
33
- * One element that says whether the whole app has finished, and what is open.
34
- *
35
- * `[data-app-phase="ready"]` is the entire readiness contract for anything
36
- * driving JBrowse from outside — a screenshot tool, a test, an agent. Wait for
37
- * that selector and you are done; there is no chain to assemble and no
38
- * per-display census to take.
39
- *
40
- * Why it exists when `data-view-phase` and `data-display-phase` already do:
41
- * those are per-element and NEGATIVE. Asking them "is everything finished"
42
- * means asserting that no element carries the loading value, which is equally
43
- * true of an app that has not started — and the gap is real, measured at about
44
- * a second on a two-track session. A positive attribute cannot be satisfied
45
- * early, because something has to render it.
46
- *
47
- * The census attributes beside it — `data-app-views`, `data-app-assemblies`,
48
- * `data-app-tracks` (the latter two JSON arrays) — publish WHAT is open the
49
- * same way the phase publishes whether it is done, so an outside reader asking
50
- * "is the track I requested actually open" reads one element instead of
51
- * walking `window.JBrowseSession` with its own copy of the view nesting. The
52
- * walk itself is `openViews`/`openTracks` over each view's declared
53
- * `ownViews`/`ownTracks`, so this component knows nothing about which property
54
- * a container view keeps its children on either.
55
- *
56
- * Its own component, and `hidden`, for two reasons: an observer here subscribes
57
- * to every view's phase without re-rendering the app shell around it, and a
58
- * marker that is never drawn cannot be mistaken for UI or shift a layout. It is
59
- * still found by `querySelector`, which is what reads it.
60
- *
61
- * **What it is silent about**: a display in a TERMINAL state. `error` is a
62
- * finished state, so this reads `ready` over a display whose fetch failed —
63
- * correctly, since nothing is still working. A capture wants more than that: it
64
- * wants a picture, and an error banner is not one. `waitForDisplaysDone` after
65
- * this is what draws that line, keying on the `data-display-drawn` the two
66
- * comparative canvases publish from their stricter `settled` gate (see
67
- * `comparativeReadiness` in `@jbrowse/synteny-core`, which holds both answers
68
- * and says why an error separates them). Both harnesses do it in that order.
69
- */
70
- const AppReadyMarker = observer(function AppReadyMarker({ session, }) {
71
- const views = openViews(session);
72
- const tracks = openTracks(session);
73
- const loading = views.some(viewLoading) || tracks.some(trackLoading);
74
- return (_jsx("span", { hidden: true, "data-testid": "app-ready-marker", "data-app-phase": loading ? 'loading' : 'ready', "data-app-views": session.views.length, "data-app-assemblies": JSON.stringify([
75
- ...new Set(views.flatMap(v => v.assemblyNames ?? [])),
76
- ]), "data-app-tracks": JSON.stringify(tracks.map(t => t.configuration.trackId ?? '(unnamed)')) }));
77
- });
78
- export default AppReadyMarker;