Re: Download navigation UX

On Wed, Jul 8, 2020 at 5:56 PM Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Wed, Jul 8, 2020 at 4:16 PM Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
>
>>
>> They're in separate files because they are setting up event handlers
>>> specific to each page. I don't know of a way to do that with a shared file
>>> without jumping through some likely hacky and fragile hoops to allow the
>>> code to figure out what page it's been called from - i.e. making sure that
>>> certain DOM IDs are always unique across any pages the shared file is
>>> called from, and testing for the existence of those IDs to figure out what
>>> event handlers to setup at runtime.
>>>
>>
>> We already do similar in forms.js, though I have to admit a lot less than
>> I thought we were. I guess I'm getting it slightly confused with other
>> repos.
>>
>
> That's a *lot* more generic though from what I can see.
>

Yea.

> We *already* have the requirement to keep "certain DOM Ids" unique -- we
>> use it for CSS. And I really don't see that as any bigger problem than
>> keeping the filename of the JS file unique.
>>
>
> Do you have an example? I can't see any obvious ones. Ideally we should be
> using classes for CSS imho, rather than IDs anyway imho (and we really
> shouldn't be using IDs in a way that requires them to be unique across
> pages that may well be unknown to the casual hacker - that would be a real
> maintenance headache).
>

Hmm. Looking at it it's fewer than I thought, because we have tons of CSS
rules that aren't actually in use. But if you want a recent example,
release-notes. And the navigation.

What would be the reason to use classes for things that are only supposed
to appear once? I thought the entire point of classes vs ids in the rules
are classes for things that there can be more than one of, id when it's a
unique identifier.

Having the separate files is certainly an extra download and slightly less
>>> cacheable (for a few bytes of code), but I think that's outweighed by the
>>> additional complexity and code that having a single file would require.
>>>
>>
>> It's really more the latency than anything else. I'm pretty strongly on
>> the side of thinking the cost of that is higher than the small amount of
>> complexity -- I really don't think it would be much. But no, I'm not
>> strongly *enough* on that side to actually try to produce proper metrics to
>> prove it :)
>>
>
> The code complexity isn't that much I grant you. We'd have to wrap
> something like the following around each event listener setup:
>
> var elem = document.getElementById("elementID");
> if (elem) {
> // setup listener
>
}
>

Yeah, or the same for classnames if that makes you happier :)

I don't really consider that very complex. We already inject jquery on all
pages, so you could use that to simplify it even more. But I would suggest
not doing that -- it would be nice to at some point be able to remove
jquery as a dependency, so iet's not dig that hole deeper.

However the cognitive complexity for the maintainer/developer of ensuring
> IDs are unique across different pages is *much* higher.
>

I still don't see how those are very high. What's the likelihood of using
an id like "yumdownloads" (or similar) on a page that is unrelated to yum?
I'd say that's pretty much zero.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>