Tags on photos can now have timestamps, so that if you are tagging
a video or audio you can reference a specific moment with your tag.
In the interface, this means the tag is clickable and seeks to that
point in the media.
For the user interface, I am finding I need to move away from jinja
for the object cards because it is too much hassle to keep the code
for jinja-based cards for static rendering and the js-based cards
for dynamic rendering in sync. Rather than write the same cards in
two languages I can dump the JSON into the script and render the cards
on load. Which makes the static HTML worse but that's what the JSON
API is for anyway.
The current system has bad performance when you've got 100,000+ tags.
I discovered that when the server returns 304, the browser gives the
ajax a 200 with the full response, and it's not clear to me if js can
know it got a 304. So, the tag set is being fully re-parsed from the
response on every page load. I was thinking that I should store that in
IndexedDB to avoid the parsing step, but... since the JSON.parse is
done by my common.get before it hits this function, it's meaningless.
Not to mention I still have to rebuild the datalist on every page since
of course that state isn't shared between tabs. Not worth the DB stuff.
We'll see what happens next.
On the main tag listing, for child tags, you only get an unlink
button on hover. So if you want to delete a child tag you'd have to
unlink, then refresh, then delete. Now you can just go to its page
and delete it there.
This will help keep the code on the pages focused more on the
page-specific stuff like form handling, and less on the raw api.
Plus, by having it all in one place, it can be cached
and also we can use any api from within any page.