yonluandClaude Opus 5
deb3f3da7e
make e2e is green on chromium: 92 passed. The harness is rebuilt on
what v3 actually offers, and three of the four things it replaced turn
out to be better than what they replaced.
The headless launch is v3's own server mode. scripts/dev-headless.sh
ran a `-tags dev` binary whose app_dev.go parsed -devserver/-assetdir
out of os.Args; that file went with v2, so the harness had no server at
all. `-tags dev,server` is a first-class mode and needs no display, so
Xvfb is gone from the script and from CI.
The bridge hooks two places, neither of them EventsOn. Inbound is
window._wails.dispatchWailsEvent, wrapped by pre-creating the object
the runtime keeps and putting an accessor on the one property.
Outbound is fetch: v3 routes every runtime call through one POST, so
the bridge sees binding calls and event emits from any module, needs no
walk of an object graph, and cannot miss a call made before it looked.
__yjEvents.call posts to that endpoint by method name, so it depends on
nothing in the app's bundle and works on a page with no init script.
That is what lets seed-sandbox.sh drop playwright-cli entirely — it
drove AddLibrary through a browser only because window.go was v2's one
way in — and with it a global npm install and a second Chromium in CI.
measure.mjs and one spec lose their window.go walks and read the
bridge's log instead; e2e/support/method-ids.mjs derives id -> name
from frontend/bindings/ (phase 6b option 1, so it cannot go stale
silently). Plain .mjs because measure.mjs runs under bare node and one
derivation beats two that can disagree.
Four bugs surfaced, and the migration is how.
The cross-service wiring never ran headless. It hung off
Common.ApplicationStarted, which server mode never emits —
setupCommonEvents is an explicit no-op there — so the queue had no
TrackLoader and playing a track changed the queue and then silently did
nothing. It is a service registered last now (backend/startup.go):
services start in registration order, which is the ordering the wiring
needs, in every mode.
Six specs called SetQueue with 3 of its 4 arguments. v2 accepted that
and filled the gap; v3 answers "expects 4 arguments, got 3".
requested-badge's cleanup read window.go and returned early on
`if (!svc)` — the silent cleanup its own comment was written to
prevent, one migration later. It posts to the runtime endpoint now,
which any page can do.
SearchIndex.Search trusted a startup latch, so rows a spec staged
afterwards were unsearchable and three specs passed only when an
earlier one happened to flip it. shelves.go fixed exactly this and left
hasCatalogRows behind; the search path now uses it as the fallback,
with the latch still the fast path.
Two spec edits are deletions of assertions about v2. harness.spec
checked Object.keys(window.go) and that a bad call *hung*; it now
checks the real runtime is loaded and that the backend rejects with a
TypeError naming the argument. album-actions asserted a tracklist
legend that dcc40b1 deleted on main — that spec has been failing since,
and what replaced it is covered in frontend/test/components.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm
54 lines
2.1 KiB
Go
54 lines
2.1 KiB
Go
package backend
|
|
|
|
import (
|
|
"context"
|
|
|
|
"github.com/wailsapp/wails/v3/pkg/application"
|
|
)
|
|
|
|
// startupService is the cross-service wiring, wearing a service's
|
|
// clothes so the runtime starts it like everything else.
|
|
//
|
|
// The wiring belongs to no single service — it is the hooks, adapters
|
|
// and callbacks that make one package drive another — so v2 put it in
|
|
// OnStartup and the first v3 port hung it off
|
|
// events.Common.ApplicationStarted, which fires after every service's
|
|
// own ServiceStartup and is therefore the right *moment*.
|
|
//
|
|
// It is the wrong *mechanism*, because server mode emits no
|
|
// application events at all: v3's setupCommonEvents is an explicit
|
|
// no-op under `-tags server` ("server mode has no platform-specific
|
|
// events to map"). So the desktop build wired itself and the headless
|
|
// build did not, which showed up as "No player set, cannot load track"
|
|
// — the queue had no TrackLoader, so a track played from the UI
|
|
// changed the queue and then silently did nothing.
|
|
//
|
|
// Registering last is what preserves the ordering the wiring depends
|
|
// on: services start in registration order, on the main goroutine,
|
|
// before the platform run loop (application.Run's startup closure), so
|
|
// every service this touches has taken its context by the time this
|
|
// runs. A service is also the honest description of what this is —
|
|
// something with a lifecycle the app owns — and it costs no bindings,
|
|
// since ServiceStartup and ServiceShutdown are excluded from them.
|
|
type startupService struct {
|
|
app *YellowJacketApp
|
|
}
|
|
|
|
// ServiceStartup runs the app-level wiring.
|
|
//
|
|
// OnDomReady no longer means the DOM is ready — nothing in v3 offers
|
|
// that — and it does not need to: what it does is start the soft
|
|
// rescan and report a startup failure, neither of which wants a
|
|
// frontend. The frontend drives its own state synchronisation by
|
|
// calling EmitCurrentState once its stores are listening, which is
|
|
// what makes the rename harmless.
|
|
func (s *startupService) ServiceStartup(
|
|
ctx context.Context,
|
|
_ application.ServiceOptions,
|
|
) error {
|
|
s.app.OnStartup(ctx)
|
|
s.app.OnDomReady(ctx)
|
|
|
|
return nil
|
|
}
|