Files
yellowjacket/frontend
yonluandClaude Opus 5 edb13a6f39 perf(explore): ask the disk once, prefetch once, and menu the releases
Three things on the Explore surfaces, all about not asking twice.

A portrait already on disk costs no network call. explore-view seeded
only from the library store — owned artists, which on a catalog search
is nearly none of the results — and sent everything else to
GetArtistImageURL, the resolving entry point, one await at a time.
GetArtistImagesCachedPaths asks the disk about every unresolved artist
in one call, and only what it does not answer reaches the resolver,
in parallel.

The artist page's two sections both wanted PrefetchReleases and each
called it, so the most expensive call the app makes was issued twice
for an overlapping set on a 1 req/s limiter. They are collected and
sent once on a microtask, and prefetchRequested stops the cold-artist
refetch re-asking for what it already asked for.

The release cards — most of the artist page — had no context menu at
all. They have one now on both release shapes, normalised to a
ReleaseMenuTarget when the menu opens so the union does not reach the
action handlers. It is a discriminated union rather than one nullable
field per kind because the panel is shared with the track menu: that is
what keeps aria-label moving with the target, which is the fault
cover-grid shipped. Which items appear is three different questions —
playback is gated on a local album id, not on "owned", and the request
needs a catalog MBID, so it is absent for a library-only release.

Note on the docs: the CLAUDE.md and NOTES.md prose here was
reconstructed after a mishandled `git stash --keep-index` destroyed the
uncommitted originals. One NOTES.md section is marked as incomplete
where its text could not be recovered.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UDCbcCZQepnpSQYJ6SxxZm
2026-08-14 13:34:15 -04:00
..
2025-03-28 11:43:14 -05:00

YellowJacket Frontend

This directory contains the frontend for YellowJacket.

Dependencies

There are a couple of tools that are required to build and use the frontend.

  • vite for
    • transpiling typescript
    • bundling the final "package" that is useb by the webview
    • running a dev server with hot-reloading
    • configured with the vite.config.ts file in this directory
  • pnpm for managing frontend dependency packages

There are a handful of dependency packages that we use directly in the frontend.

Lastly, there are some dependencies that only benefit development

  • tsserver comes bundled with vscode and can be used as an LSP with other editors using typescript-language-server
    • Used for autocomplete, syntax highlighting, etc.
    • This can be configured with the tsconfig.json file in the root of the project
      • NOTE: your configuration should align with the vite config so you get in-editor feedback that aligns with how the build will be done.

Development

Ideally, you would use the frontend in the wails app as the frontend depends on the Go bindings generated by Wails. You can do this by running wails dev in the root of the YellowJacket repo.

If you want to run the frontend standalone, make sure the Wails go bindings have been generated with wails generate modules. Then, you can run pnpm dev to run the vite dev server. For more information on what commands are available, refer to package.json.

Code

Web Components

Our frontend is based off of Web Components, a standard that provides native browser encapsulation of components that can include HTML, CSS and Javascript all together. Instead of writing these components manually in Javascript, we utilize lit as a wrapper library.

Typescript

To better integrate with our tooling and to provide a better developer experience with strong typing, we have written all functional frontend code in Typescript. Vite serves as our Typescript transpiler.

Important Files and Directories

NOTE: most of these directories have aliases defined in tsconfig.json and vite.config.ts so that we may refer to them by shorthand when importing.

  • index.html and index.js is the entrypoint for the frontend. The first page that loads.
  • wailsjs/go Go code bindings generated by wails reside here
  • wailsjs/runtime the Wails runtime code needed to use Wails features
  • src all app code resides here
  • src/assets static assets like fonts, images and icons
  • src/components lit components that are used to compose the application
  • src/pages pages that serve as other entrypoints for the application that can be navigated to