logan
b5d70ac1cd
The complaint was having to notice the metadata was missing, then go and hunt the album down on the Autotag page. The album page now says it while you are looking at the thing: "MusicBrainz has a match for this album: <release> by <artist>", with Apply tags and Review in Autotag. Four things about it are load-bearing. **Applying is offered only where it would do the whole album.** A tagging group is a folder, so a multi-disc album is several, and one button that applied to the best-scoring group would leave the album holding a mix of old and new tags — the exact case the app's Blocking notification level exists for. `groupCount` is the test, and the answer there is review rather than apply. **It rewrites files, so it asks.** `confirmAction()` with an impact line that says it cannot be undone and that nothing is moved or deleted, because "rewrites your files" reads worse than it is. The apply goes through `ApplyAsync`, the registered-job path, so progress belongs to the jobs indicator and this page does not grow a second one — what it owes the user is the acknowledgement, because the button is here. The suggestion clears itself on success rather than inviting a second click while the job runs. **The banner does not quote a percentage.** The backend has a score and deliberately keeps it out of the sentence: 0.95 reads as a probability and is not one. Which release it is, is the part a person can judge. **"Review in Autotag" lands on that album.** The queue is sorted by score so the intended folder is often near the top, and "often" is a link that sometimes opens a different album. Autotag is a cached primary view, so there is no construction to hand a payload to: the request goes on as an attribute and the view *consumes* it, or every later visit would reopen a folder the user finished with long ago. `ICON_AUTOTAG` joins the vocabulary at the same time, on the rule `ICON_PLAYLIST` was chosen by — an icon names the noun it acts on, so a suggestion pointing at Autotag wears the Autotag destination's own mark. It was written inline in the sidebar; two call sites is where a name stops being one component's detail, so the sweep governs it now. Verified against the running app with a staged match: the banner, the confirm dialog's wording, and the navigation landing on the right folder with the attribute consumed. Closes #28
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