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.
I'm having some performance issues with button_with_confirm on /tags.
This won't magically make that faster but I'm trying to stop the main
thread from dragging at least.
Following the previous commit about the checkbox on the /photo page,
this fixes all of the code assuming that we're dealing with photo_card
divs, the majority of which was doing nothing but accessing the id.
I think my original reason for doing this was to prevent the button
from being operational until after the spinner initialization has
completed, so you don't get any weird half-functional spinner buttons.
However, in practice I'm finding that I constantly forget about this
and it adds tedium to creating spinner buttons.
Will review if any actual problems come up.
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 hook had a bug where you couldn't select text because every
time you push a button, including ctrl+a or shift+left/right, the
cursor position gets reset and then deselects immediately.
So let's only reset the content and cursor only when text changes,
so arrow keys and ctrl don't have any negative effects.
Unfortunately, when adjusting the box's value, it causes the datalist
to disappear, and it only comes back after you press another key.
I can't figure out how to make the datalist reappear automatically
with js.
This was less helpful than expected, because if you take that
tab and navigate somewhere else, then trying to open the clipboard
would replace the current tab instead of opening a new one.
The markup for the album listing page and individual album page
were different enough that I decided to make them wholly separate,
but then this left the shared javascript in its own stupid file
unlike any of the other types.
So, I'm merging them as a huge jinja if-else, which is also dumb
but it feels better than all these separate files.
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.
The javascript is very inconsistent between pages. I'm trying to
start using a consistent pattern where the api call is kept in a
separate function from the ones that buttons and input boxes
talk to.
Instead of embedding the entire tag list in the search.html template
every single time, this script loads the tags from the new,
cache-enabled endpoint /all_tags.json. Then we can use html5
datalists to create autocomplete forms on the search and photo pages.
