This prevents the specific tag from being included in the results in
the first place, and has the knock-on effect that the descendants'
lines won't all start with the parent tag's name.
Primarily affects the "unlink" / "delete" buttons on /tags.
Without the padding we can get an extra pt of font size, and these
buttons are somewhat of a readability struggle.
Instead of defining the function with an internal if that will always
pick the same path, let's use that if to instead define a
straightforward function that just does what we want.
Since meta.status would be undefined for an incomplete request,
I would have to check response.completed && response.meta.status,
which is too much burden. Let's set the status immediately, and
if a callback wants to do further diving we'll use completed then.
I want to reduce some complexity around here, part of which is that
launch imported entrypoint imported backend, all to do some proxy
wrapping which isn't necessary for the dev case anyway. Less
layers of wrapping and importing is good. Plus I think this naming
is more clear.
Previously, then the tags list was very long and dominated the scroll
height of the page, the #right and thus the photo would be floating
halfway down the page. By making it sticky, the photo always occupies
the correct position in the viewport no matter how long #left gets.
- tag_autocomplete.tags and .synonyms are separate vars, not in tagset.
- tag_autocomplete.tags is now a Set object for faster resolve().
- get_all_tags moved to api.js.
- server provides "updated" timestamp with the all_tags list.
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.
This experiment of bringing Photos and Albums closer to parity in
search is going well so far. I have found some situations where it
is nice to only get albums back from search results.
There was always some semblance that two blank lines has some kind of
meaning or structure that's different from single blank lines, but
in reality it was mostly arbitrary and I can't stand to look at it
any more.
Any properties that are different in wide/narrow mode should be defined
in the correct media query. I got tired of having wide mode be the
default and then narrow mode having to unset/initial all the attributes
that aren't relevant to narrow.
It turns out that last-of-type only considers a single tag type,
it doesn't select last element of class if it has a different tag
than the other classed elements.
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.
Foolishly, I was checking the length of the outputted easybake format,
which included lines for synonyms and multi-parent tags that shouldn't
be part of the tag count.
I'm currently running an experiment where albums are also included in
search results, but they don't cost you any of your limit parameter.
So the len(results) was often bigger than limit and tricking this
paginator into thinking we needed a next page when really we didn't.
This workaround can be undone when I decide how to make the album
results more official.
I skipped them during the commit where I added return to all onclicks
because I figure I won't be wrapping these kinds of attributes.
But I feel like it's better to be consistent and you never know when
it might happen.
