logan
7d9e0bf2fb
An event carries what a consumer needs so it never has to invalidate. - `library-store` answers `TrackPlayCountChanged` by patching one track, replacing the tracks array (consumers key memoized caches on its identity) while sharing every unchanged Track — instead of discarding four collections and refetching 25 MB per song. - `playlist-store` answers `PlaylistTracksChanged` by refetching the one playlist the event names, plus the summaries, since `UpdatedAt` is a sort key. 2 668 kB and 172 ms for one heart, against 2.0 kB. It falls back to a full invalidate only where a patch cannot be shown to be equivalent: no id, a cold cache, an unknown id, or a fetch already in flight. And a store with no subscriber fetches nothing — the singleton's constructor used to put every track of every playlist on the path to first paint for a view the user might never open. - `library-store` guards every fetch with a cache generation and holds the request itself instead of deriving a promise from subscriber notifications, which fixes the library-filter race and the never-settling waiter together: they are the same bug seen from either end. - `explore-cache`'s two art caches are bounded, sharing one exported cap constant — the artist photo's data URL is held by both, so capping either alone frees nothing at all and reads as a fix that did not work. - `search-store` deliberately does *not* coalesce its notify: deferring makes a subscriber that unsubscribes synchronously after a `setTerm` miss the notification entirely, which is a semantic change rather than an optimisation, and this is the store on the keystroke path. - `selection-controller` retains its keys across a refetch rather than clearing them, since they are file paths and those survive one, and `getSelectedKeysOrdered()` gains an early exit. It stays a walk of the list: an index goes stale on any re-sort, re-filter or refetch while a file path survives all three, and 3 ms does not buy a silently mis-ordered queue insert.
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