-
Notifications
You must be signed in to change notification settings - Fork 20
feat: Rewrite module loader #193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -10,6 +10,8 @@ import type { | |
| HarmonyTrack, | ||
| Label, | ||
| LinkType, | ||
| ReleaseOptions, | ||
| ReleaseSpecifier, | ||
| } from '@/harmonizer/types.ts'; | ||
| import { type CacheEntry, MetadataProvider, ReleaseLookup } from '@/providers/base.ts'; | ||
| import { DurationPrecision, FeatureQuality, FeatureQualityMap } from '@/providers/features.ts'; | ||
|
|
@@ -22,7 +24,7 @@ import { similarNames } from '@/utils/similarity.ts'; | |
| import { toTrackRanges } from '@/utils/tracklist.ts'; | ||
| import { simplifyName } from 'utils/string/simplify.js'; | ||
|
|
||
| export default class BandcampProvider extends MetadataProvider { | ||
| export default class BandcampProvider extends MetadataProvider<BandcampProvider> { | ||
|
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why did you (have to) use the template type parameter for some provider classes, but not for all of them?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I hope I can explain this properly, because maybe I don't understand it fully myself. The pattern That's why In my C++ brain, this behavior reflects passing a This is important when handling multiple instances of different derived types. If all these types are reduced to Similarly, if a function expects to receive a parameter of type In my experience, class inheritance is mostly a pain in TS/JS, and you can work much more comfortably through composition. I've written large code bases in TS with extensive class hierarchies, coming from C#, and I've had a really hard time digesting that this should be "all wrong", because I felt like it works just fine, except for a few weird/rare issues. What really helped me was the advice to think about the type system as set theory. My thinking was around the most common denominator (the base class), and interacting with that. What you really want, is to interact with the superset of all derived classes, and then trim off the parts you don't want (through narrowing). |
||
| readonly name = 'Bandcamp'; | ||
|
|
||
| readonly supportedUrls = new URLPattern({ | ||
|
|
@@ -52,7 +54,9 @@ export default class BandcampProvider extends MetadataProvider { | |
| month: 9, | ||
| }; | ||
|
|
||
| readonly releaseLookup = BandcampReleaseLookup; | ||
| releaseLookup(specifier: ReleaseSpecifier, options: ReleaseOptions = {}) { | ||
| return new BandcampReleaseLookup(this, specifier, options); | ||
| } | ||
|
Comment on lines
-55
to
+59
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's a nice improvement as well, I never really liked the idea of assigning a class to another class' property. |
||
|
|
||
| override extractEntityFromUrl(url: URL): EntityId | undefined { | ||
| const albumResult = this.supportedUrls.exec(url); | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -70,22 +70,21 @@ export default class TidalProvider extends MetadataApiProvider { | |
|
|
||
| override readonly availableRegions = new Set(availableRegions); | ||
|
|
||
| protected releaseLookup: typeof TidalV1ReleaseLookup | typeof TidalV2ReleaseLookup = TidalV2ReleaseLookup; | ||
| releaseLookup(specifier: ReleaseSpecifier, options: ReleaseOptions = {}) { | ||
| return new TidalV2ReleaseLookup(this, specifier, options); | ||
| } | ||
|
|
||
| override readonly launchDate: PartialDate = { | ||
| year: 2014, | ||
| month: 10, | ||
| day: 28, | ||
| }; | ||
|
|
||
| override getRelease(specifier: ReleaseSpecifier, options: ReleaseOptions = {}): Promise<HarmonyRelease> { | ||
| getRelease(specifier: ReleaseSpecifier, options: ReleaseOptions = {}): Promise<HarmonyRelease> { | ||
| if (!options.snapshotMaxTimestamp || options.snapshotMaxTimestamp > tidalV1MaxTimestamp) { | ||
| this.releaseLookup = TidalV2ReleaseLookup; | ||
| } else { | ||
| this.releaseLookup = TidalV1ReleaseLookup; | ||
| return new TidalV2ReleaseLookup(this, specifier, options).getRelease(); | ||
| } | ||
|
|
||
| return super.getRelease(specifier, options); | ||
| return new TidalV1ReleaseLookup(this, specifier, options).getRelease(); | ||
|
Comment on lines
-81
to
+87
Owner
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think this method is called anymore after your changes. You should port the selection logic here to the new
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Then this is probably the reason for the failing test. I'll have another look this evening. |
||
| } | ||
|
|
||
| constructUrl(entity: EntityId): URL { | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like how you addressed the "uncaught in promise" issue by simply wrapping the lookup function into another function which is only called when we actually want to start all the lookups.
I definitely would like to merge (or cherry-pick) this as a separate commit with some more fitting variable names, maybe something like
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Although I wasn't so sure anymore if this even provides any benefit. I would definitely move this to a separate change.