Request: Use EventCatcher for Very Long Lists

[TW_Tones]

@pmario

It has to do with ultra long lists of tiddler links, where the generation of TWs JS event handlers is the slow part.

Is this improved with the separate event catcher design I have heard of a number of times?

If so could we not provision a code pattern, if not a large list solution designed for this use case?

In most programming languages when something is used every day, then extended to larger numbers they naturally slow down and a new method with more efficiency is developed to improve things. The poor performance forces the designer to give up or innovate, if at this point they go looking to address large lists we have a code pattern or additional language support.

If we expect this to happen could we not introduce documentation, code patterns or an optimised list solution, to reduce the impact of large lists?

[pmario]

@TW_Tones

Is this improved with the separate event catcher design I have heard of a number of times?

Yes. Using the event catcher you need a list template, that does now use the link-widget.

@TW_Tones

If so could we not provision a code pattern, if not a large list solution designed for this use case?

That’s a very valid request. I’ll create a GH issue for that one.

We could rewrite our default list-related core macros. But this will probably cause backwards compatibility problems, for those users, which have customised them.

We may need new event-list macros, that do not cause compatibility problems, but are easy to upgrade. So we need to extensively document the update path.

I think that’s one of the main reasons, why nobody did touch them yet. It’s a significant amount of work.

I am also not really sure, how a generic event-list pattern should look like, to cover as many usecases as possible. Which parameters should they have … and so on.

I could have a closer look at my Lucide Icon related editions, where I have used the event-catcher in production the first time. Especially the tagged list is challenging. It shows ~2800
tags and in average 6-10 SVG icons each. So one tiddler shows about 20k+ of icons / other tiddlers.

Depending on the age of you PC this can still need several seconds to show them all. But the default lists would have completely bricked the page.

@TW_Tones

If we expect this to happen could we not introduce documentation, code patterns or an optimised list solution, to reduce the impact of large lists?

I think we need to start small. So may be the first elements to optimise are the long lists that are native to the core UI in the sidebar.

That will probably solve about 40% of the default annoyances that users with many tiddlers have.

Also there are not many users, that actually know, what’s needed, because they need it themselves.

Also we can not use new functionality everywhere in the core, because of backwards compatibility concerns.

For every TW version since v5.3.x, which has a shorter LifeTime than 100 days, it was a bugfix release with at least one backwards compatibility fix for updated core UI elements.

So it’s not easy, no fun and very time consuming.