Configure "find" behavior on Thing classes #394
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Yay! This is a follow-up to #386, and unlike that PR, it includes a few significant behavior changes.
There are a lot of changes in this PR; it'd be split into separate ones if possible, but all the core changes work together and can't meaningfully be separated from each other.
find
from#find
, with one exception that doesn't actually correspond to any Thing subclass (find.listing
).bindFind
utility function.[Thing.findSpecs]
, which may define multiple "find" functions. These definitions are in the same format as before, except with one new property:bindTo
controls the wiki data array bound inbindFind
.bindTo
is a string, not, say, a function ofwikiData
, because no complex filtering or logic should be performed here; it's purely for controllingbindFind
. Filtering remains available through theinclude
function on a find spec.find
andbindFind
in terms of[Thing.findSpecs]
, working with new utility functionsgetAllFindSpecs
andfindFindSpec
.find
is now a Freakin' Proxy, and actually the first (non-debug) use of proxies in HSMusic, despite us knowing about 'em for years! It's done this way so that references likefind.artist
still have meaning before theArtist
class even exists. We thought this was crucial becausefind
functions are very often referenced as part of a Thing constructor'sgetPropertyDescriptors
phase... but, well, you know, the class constructors (including their static[Thing.findSpecs]
value) are extant by that point... but it's kept this way anyway for reference and ready availability.find
proxy is to facilitate getting a unique, reliable identity for functions likefind.album
before Thing constructors are actually ready. This function will error when called if Thing constructors still aren't ready, but its identity is available for static storage right away. We try to reduce general overhead as much as possible; the identity itself is just(...args) => behavior(...args)
, wherebehavior
replaces its own identifier with the usual output offindHelper(spec)
, once that spec is actually available.artistData
andartistAliasData
into one. This is analogous to howartTagData
contains both normal art tags and content warnings; for consistency and simplicity, we're going with that. The usualfind.artist
function is adapted and will never match aliases, so stuff consuming that doesn't need to adapt at all, but listings and other data or content code that directly accessartistData
(orartistAliasData
) now filter as appropriate, like uses ofartTagData
.artTagData
into two arrays, is that artists and artist aliases share the same directory namespace — that's largely the point of aliases (at the moment), so that old URLs will redirect you to the right artist. It's trouble if an artist and an unrelated alias, or two unrelated aliases, share directories!artist.js
for details; the point is to avoid having conflicting directories where we already know the common directory belongs to the obviously correct original artist. (Two aliases sharing a computed directory is also OK and ignored, since both would end up redirecting to the original artist.) This is all a bit clunky and kind of counter to how directories are supposed to work anywhere else on the website, so there's absolutely room to revisit it later on, but this enables directory deduplication between artists and aliases while essentially preserving previous behavior.filterDuplicateDirectories
is renamed toreportDuplicateDirectories
and has all of its filtering code removed, because as of 940b2cb (no PR, sorry!?) we just cancel the build if any duplicate directories were found — filtering behavior isn't needed anymore. This also cleans up the way the internal aggregate error is handled — it's just closed and thrown like any normal aggregate-throwing function, and this is caught and displayed byupd8.js
, instead of having upd8.js access and close the internal aggregate itself.