Eventcatcher request for giffmex.org/b/

#1

Hi everyone

In a different thread the other day, @CodaCoder wrote this about my Spanish searchable TW index (Índice central — giffmex.org/b/):

If you were to wrap your head around the eventcatcher widget, you would see a quite dramatic improvement in rendering speed for those lengthy lists of links.

I took a look at eventcatcher and can’t make heads or tails of what it is, what it does, what to use it for, or how to do so. Also, I wasn’t aware that my site was rendering slow. You guys must really work fast to notice rendering speed changes that minute.

Anyway, I don’t really want an explanation. Mario and Eric, among others, I enjoy your detailed explanations, but this is one I will gladly sit out and let someone else figure out. This is a “call the plumber” post, not an “I want to start a DIY project” post.

Now the request: If anyone would want to beef up my macro(s) with eventcatchers in a way that significantly reduces the rendering time of my list-searches on that site, like @CodaCoder suggests, I will donate $50 to the TiddlyWiki dev thingy this week. Here are the macros. Assuming it is the macros that need tweaking…

Please: reply here BEFOREHAND if you want to tackle this, so others will know and we can avoid duplication of efforts.

$:/.giffmex/Macros/EntradaText
$:/KISS List-Search Macro fecha
$:/KISS List-Search Macro formato
$:/KISS List-Search Macro tema
$:/KISS List-Search Macro titulo

EventCatcher DIY
#2

I would be keen to help to drive some funds to tiddlywiki, Having a quick look at the site it is occurring in the vertical tab “Materiales x título” that the list activates a macro per tiddler, which is not simply a link but also a details statement?

  • If these were reduced to a simple list of links, and place the content of the last clicked link in the side bar, it may be more performant, that is possibly, without any catcher.
  • Regardless if only trying to catch links the LinkCatcherWidget is a simpler way to implement it than the generic catcher widget.

No I am not yet committing to do this, but may in the near future.

#3

Hi @DaveGifford, I was in a similar boat hearing the recommendations of eventcatcher here on Talk but not really understanding it, so I just tried blindly implementing it with help from others. My lists are actually probably not big enough to notice, but I did get it working. I know you said you don’t need to understand it, but maybe for future searchability for myself/others I thought I’d share a comparison to a “normal” workflow based on my experiments. This at least gives me an idea of the pattern. I made the parts to change obnoxious with ALL CAPS so it’s most obvious which things are important and need to stay (like the dom-) vs what you use.

Normal way

<ul>
<$list filter="[tag[TableOfContents]]" variable="ME">
<li><$link to=<<ME>>><<ME>></$link></li>
</$list>
</ul>

Eventcatcher way

\define MYACTIONS() <$action-navigate $to=<<dom-MYPARAM>> />

<$eventcatcher selector=".MYCLASS" $click=<<MYACTIONS>>>
<ul>
<$list filter="[tag[TableOfContents]]" variable="ME">
<li><a class="MYCLASS tc-tiddlylink" style="cursor:pointer;" MYPARAM=<<ME>>><<ME>></a></li>
</$list>
</ul>
</$eventcatcher>

Note I made a couple design choices to maximize comparison

  • The “normal way” would normally be simplified I realize by not setting a variable and just using <$link/>
  • You’d probably want to move that style="cursor:pointer;" somewhere else rather than inline (or omit)

Certainly I’m not an expert, so hopefully one of the real experts corrects me if I got that wrong.

2 Likes
#4

That’s a nice example, @stobot. :clap:

@DaveGifford

The key point is that $eventcatcher provides a single point of capture for click events. All clicks coming from any list item inside your list is handled by ONE click handler in ONE place. In JavaScript parlance, this is known as a “delegate”.

When you have $link, $button, <a href="x"> etc, included in a $list (and in your case the loop iterates many times), you may have hundreds (perhaps even thousands) of click event handlers. The TW core (and indeed the browser) needs to spend considerable periods of time “wiring up” and rendering all those click handlers. Repeat: with $eventcatcher, you only have ONE click handler, a single delegate.

More info:

1 Like
#5

Thanks Tones, Stobot and CodaCoder! I feel more informed now about why this is important.

The offer is still on the table. Sounds like it is just a matter of adapting Stobot’s code to the lists on my site. If anyone wants to do that, that would be great, and I can issue the payment on the TW devs website.

#6

I should specify that Tones’ suggestions about making them simple links and/or moving things over to the sidebar are not options for me. The details element allows users to quickly access links to the format and topical indexes for each list entry. And most of my users access the index from their cell phones, so I have very deliberately hidden the sidebar.

#7

:dart:
   

It just so happens that @stobot used HTML <a> elements which are typically used as “links”. But you can use any element is the click target, <span>, <li>, <p>, etc.

#8

Perhaps in this case a details element?

My question would be if there is anything more than just some content the event catcher reacts to, see @DaveGifford links and select tabs until you get the performance issue, could the code just introduce a whole new set of events that drag down the performance, in this case the drop down and its table?

#9

If you decide you’re interested in DIY, I wrote up a response in EventCatcher DIY.

1 Like