I wish I could recommend Pocket Casts, a free and open source podcast player. I don't, however.
This is the code that I developed to export my listening history from Pocket Casts. Figure it out.
The header and payload properties could be
memoized. It would only take a little bit of code, but still too much to
be considered worth it. It's not clear that that would optimal, besides.
Use destructuring assignment (like the way it's done in
PocketCastsJWT.from) if it's a concern.
It would be useful to track all JWTs that PocketCastsJWT
retrieves from the server (read: passively aggregate a collection of
them), so as to make them available for re-inspection and minimize chatter
that might be considered a nuisance (or raise flags) at the server. It's
not hard to get something like that to work. Viz:
(You might wonder, "Wait, why not subclass PocketCastsJWT
and get the Interceptor to fix up the symbols — or do
the fixup directly in main (see below)?" That's a good
question; perhaps that would be better. I didn't do it like that,
though.)
It's useful, too, to be able to get confirmation of success or failure
when tokens are retrieved by seeing evidence of their existence by having
them automatically logged at the time of retrieval. We've already placed
an onscribe hook in the interceptor.
For EpisodeCollection, the "shape" of intended use matches
the same pattern that PocketCastsJWT is supposed to follow.
They both have retrieval methods. The idea being that you can obtain a
JWT (based on the server response to the JWT retrieval method) and use it
to empower/entrust (i.e. authorize) the creation of a
EpisodeCollection — the contents of which is also
dependent upon how the server responds to its retrieval request.
(Note that we don't make the retrieval for the star collection pass a
similar checkOrigin test of the sort used for the JWT. We
could, and if we were being thorough, we would probably refactor things to
do that. We're far from being thorough here, though.)
Access tokens have a short expiry.
The live export object will have all the data when the process is finished, but without a reference to the object, the data will be impossible to access.
The idea with DataExportHelper, like the
Interceptor from before, is that its attach
method allows dynamically overriding the behavior of a previous class
definition (in this case PocketCastsStarsExport by default)
so that e.g. calls to PocketCastsStarsExport.start will
result in a little extra code running that will print out a URI (to the
browser console, or whatever controls the console object)
that can be used to inspect the user data.
The point of the definitions in the script blocks we've seen has been
for them to be inert — they're just simple class
specifications that don't actually do anything unless you're
doing something with the objects; evaluation of all the preceding script
blocks puts their definitions in scope, but in the case of the
Interceptor and the JWTLogger at least, things
need to be fixed up so they can can actually do their job when objects
are actually being interacted with. The same is true of
DataExportHelper.
The content of this literate program should be active — treated as valid, executable code in any viewer that is compatible with the W3C/WHATWG hypertext system (e.g. a conventional Web browser).
The following style rules contribute to the formatting and visual representation of this guide: