discography: the whole catalogue on a page of its own

"Show all" beside the artist page's Discography head opens every release
as a stack of album-page heroes with their tracklists — the shapes Kyle
picked off the mock: the search page's top-result card as a compact
header, the album hero at --cover-scale 0.45 per record, a per-record
accent sampled from its own cover, the year rail and the tab summary. The
tab row does not stick and there is no Playing badge. Records the artist
page has not fetched are shown rather than hidden, and the entrance is
the W1 stagger — 300ms in, 55ms per row, 28px of lift, eight rows.

It does not re-file the releases. catalog.discoTabs is the artist page's
OWN computed tab list, published as it derives it and republished as the
evidence improves. It has to work this way: the filing depends on the
background description harvest that runs while you look at the artist
page and on the MusicBrainz type hints from the deferred identity pass,
neither of which is derivable from the payload — so a second classifier
would read neither and would quietly file some releases differently from
the page that linked to it. One list, computed once, handed over. If the
tabs in hand belong to somebody else, opening a discography lands on the
artist page instead, which republishes them and puts "Show all" one click
away; an empty discography would be a lie about the catalogue.

The page's CSS was extracted from src/ rather than retyped — CatalogAlbum's
record section, CatalogSearch's header card and PlayerBar's menu, pulled
through the same rule-matcher the mockup generator uses — so it inherits
the app's measurements instead of approximating them. Verified against
the running app: artwork 108px, record hero 114.3, header 147.5, header
top 78, bar offset 0, ambience banner 0, rail centring error 0 and 12.8px
of clearance at every scroll depth and pane width. Pond files 12+16+2+2 =
32 families on both pages.

It is the one page exempt from BAR_VIEWS' padding-top rule, deliberately:
its blurred ambience layer has to begin at the very top of the pane, and
a padding there would start it halfway through the glass bar. It takes
the inset on its header's margin instead, which lands in the same place.
This commit is contained in:
KeelrLeek committed 2026-08-04 14:44:13 -05:00
1 parent 819a2757bc
commit 34313e6035
5 files changed
+1709 -3

No files matched your search

+15 -2
View File
@@ -19,6 +19,7 @@
import CatalogSearch from "./views/CatalogSearch.svelte";
import CatalogArtist from "./views/CatalogArtist.svelte";
import CatalogAlbum from "./views/CatalogAlbum.svelte";
import CatalogDiscography from "./views/CatalogDiscography.svelte";
import FollowToast from "./components/FollowToast.svelte";
import {
ui,
@@ -42,6 +43,7 @@
catalog: CatalogSearch,
catalogArtist: CatalogArtist,
catalogAlbum: CatalogAlbum,
catalogDiscography: CatalogDiscography,
};
const CurrentView = $derived(views[ui.view] ?? Home);
@@ -54,8 +56,19 @@
A page added here MUST also take `padding-top: var(--pane-pad)`: the bar
cancels the pane's top padding so a page's artwork can run underneath it,
and the page restores that inset for its own content. Without it the page
renders 24px too high; with it but not listed here, 24px too low. */
const BAR_VIEWS = new Set(["catalogArtist", "catalogAlbum", "catalog"]);
renders 24px too high; with it but not listed here, 24px too low.
`catalogDiscography` is the one exception to the padding rule above, and
deliberately: it pins a blurred ambience layer behind the glass, and that
layer has to begin at the very top of the pane. A padding-top here would
start it a --pane-pad down — halfway through the bar. It takes the inset
on its header's margin instead, which comes to the same place. */
const BAR_VIEWS = new Set([
"catalogArtist",
"catalogAlbum",
"catalog",
"catalogDiscography",
]);
initEvents();
autoConnect();