logan
905654cc84
Choosing which pressing you are looking at is an advanced, metadata-repair task, and it sat directly above the tracklist with a heading, a `<select>` and a paragraph explaining how our clustering picks a "standard version" by weighing release count, status and date. That is a sentence about our own heuristic in the most valuable space on the page. It is now "Other versions of this album (N)" below the tracklist: a real `<button aria-expanded aria-controls>` inside the heading that names the section, with the body rendered unconditionally and toggled with `hidden`, because `aria-controls` has to name an element that is in the DOM. Both rules are `config-section`'s rather than new ones. It is demoted, not removed — matching the wrong release is a real problem and this is how it gets fixed. **Two more blocks shared that slot and neither was guarded.** The selector at least had `distinctTracklistCount() <= 1`; the `Versions / Loading releases…` spinner and the `Versions / <error>` block did not, so both took the primary position on every album regardless of whether there was ever going to be a choice. The spinner said what `renderTracklist` was already saying about the same fetch, so it is gone. The error was the one `catalog-scope-notice` shows at the top of the page with a retry — every path that sets `errorReleases` also sets `catalogFailed`, the only route to `unavailable`. That error is what made this a rewrite rather than a move. `renderTracklist` returned `nothing` on `errorReleases` and leaned on the selector's own block to have said it, and a control inside a collapsed disclosure cannot be a page's error surface. The failure belongs to the list that is missing because of it, so that is where it is drawn. **What must not be lost is which version is on screen.** The default is what the header already describes, so saying it on every album would be this issue's own complaint one size smaller. `defaultVersionKey` is the test: a line appears above the tracklist only once someone has chosen another, naming it and offering the way back. The ★ and the words "in your library" survive unchanged inside the panel, and the panel does not close when the selection changes — a panel that shuts on use cannot be used twice. The `<select>` also loses an `aria-label` of "Select release version" that outranked its own visible `<label>Version</label>`, which is a label not in the name. Verified against the running app as well as the suite: the collapsed page, the open panel, a chosen version and 390px width all read correctly, and the shell still measures 390 in a 390 viewport. Closes #17
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.
vitefor- transpiling typescript
- bundling the final "package" that is useb by the webview
- running a dev server with hot-reloading
- configured with the
vite.config.tsfile in this directory
pnpmfor managing frontend dependency packages
There are a handful of dependency packages that we use directly in the frontend.
picocssfor basic CSS while developinglitfor a simple but powerful wrapper around Web Components
Lastly, there are some dependencies that only benefit development
tsservercomes bundled with vscode and can be used as an LSP with other editors usingtypescript-language-server- Used for autocomplete, syntax highlighting, etc.
- This can be configured with the
tsconfig.jsonfile in the root of the project- NOTE: your configuration should align with the
viteconfig so you get in-editor feedback that aligns with how the build will be done.
- NOTE: your configuration should align with the
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.htmlandindex.jsis the entrypoint for the frontend. The first page that loads.wailsjs/goGo code bindings generated by wails reside herewailsjs/runtimethe Wails runtime code needed to use Wails featuressrcall app code resides heresrc/assetsstatic assets like fonts, images and iconssrc/componentslit components that are used to compose the applicationsrc/pagespages that serve as other entrypoints for the application that can be navigated to