筛选器的上限

机杼

最近我做了一些小东西，其中一个工具是，在条目页面上有一个按钮，点开后会显示一个弹窗，弹窗里有一些关于这个条目的内容。

其中一个是上下文的内容，包括两个方面，一个方面是此条目所属的根目录，并构建一个面包屑。一个方面是关于此条目下面的子条目，链接和嵌入等内容。如下图所示。

此条目的根目录在WENAI，包含一个链接，一个标签，一个嵌入内容。

因为之前使用TiddlyWiki是好几个wiki，所以现在我的根目录有好几个，并不只有一个。

ok，现在问题来了，如果我建立一个条目，这个条目不存在那几个根目录之下，且没有链接，也没有标签，也没有嵌入。那么这个条件判断应该怎样写呢？

我知道其实这个问题并没有太大的实际用处，因为正常来说，一个什么上下文信息都不包含的条目没有查看的必要。

但因为旁边我还有其他功能，比如可以快速修改标签或字段的功能，所以我才会想着当打开一个条目，没有任何上下文时，展示出一段文字。（当然更好的做法是直接切换到其他页面去，但同样我也不知道怎么做。）

如果我要解决这个问题，也同样是从上述两方面入手。

面包屑我是使用in-Tag-tree-of，包装的宏代码里有下面这个初始判断。即判断当前条目是否属于某个给定的根目录。

<$list filter="[[$tiddler$]!prefix[$:/]in-tagtree-of:inclusive[$name$]]">

但因为我有好几个根目录，所以这个list判断应该要写好几个，且需要嵌套，因为可能需要一些循环方式，在TiddlyWiki里写循环就是用list，可惜在这一步我就不会了。

第二个方面则是关于此条目的内容，这里我是用自己之前修改kookma的宏，所构建的节点丸。

$:/plugins/mabuqian/gumo-customisation/node-explorer-colorful

\import $:/plugins/mabuqian/gumo-customisation/node-explorer
\define subtiddler-pattern() $(currentTiddler)$
\define type-class() badge p-1 badge-$(type)$

<$list filter="[all[current]get[node-explorer]!match[hide]] [all[current]!has[node-explorer]] :and[!is[system]]" variable=null>
<$list filter=<<mainFilter>> variable="currentRecord">
	<$let type={{{ 
		[all[current]links[]match<currentRecord>then[info text-white]]
		[all[current]backlinks[]match<currentRecord>then[danger text-white]]
		[all[current]tagging[]match<currentRecord>then[warning text-dark]]
		[all[current]tags[]match<currentRecord>then[success text-white]]
		[<currentRecord>prefix<subtiddler-pattern>then[primary text-white]]
		:else[<currentRecord>search:text<currentTiddler>then[secondary text-white]else[dark text-white]] 
		}}} >
			<$link to=<<currentRecord>> class=<<type-class>> />
	</$let>
</$list>
</$list>

可以从代码中看到，里面做了很多的判断条件。

那如何判断一个条目，没有标签也没有链接也没有其他类似的项目呢？难道又把上面的代码都改一遍？

更何况，这不是一个页面按钮，而是经常会用的按钮。换言之，我会经常在新建条目时，点开这个按钮。

所以每当这个条目什么上下文都没有，但上面的筛选器都要跑一遍的时候，我已经能想象到筛选器炸了或者卡了的状况了。

当然我对TiddlyWiki的底层机制不了解，所以也可能存在着更好的方式和解决办法。但一时我也没有想到。

机杼

总结来说，就是TiddlyWiki的底层机制是怎样的。怎么处理复杂的渲染，刷新，状态管理。能承受的上限是什么。

我最近折腾的小东西，感觉很吃渲染，虽然没有明显的卡顿，但能感觉到是卡了一下的。当然我写的wikitext肯定也不够好。

没有往英文论坛那边发，是感觉这个东西还没说清楚。可能下次有机会我演示一下就好了。

linonetwo

关于优化筛选器性能，这是比较专业的领域了，需要计算机科学专业的背景才能搞了，都有讨论过 https://github.com/TiddlyWiki/TiddlyWiki5/discussions/8618#discussioncomment-12854153

筛选器都是在展示出来的一瞬间才执行的，如果怕卡的话可以像我的可视化大屏插件或者意义之塔一样，把它隐藏到某个地方要用再打开。平时主界面就只放上下文比较少的专注于一小块的那种东西，需要聚合大量数据的都放到某个布局里。

当然我发现这么做最大的问题是，他就很少被打开了，偶尔才会看一次他。其实实际上也就是卡那么一下，该计算的东西都得要计算的。

我在上面链接里也建议了，最根本的解决方法还是延迟更新、减少更新，反正有时候也不需要特别及时的看到结果。

还有筛选器也不用想的太抽象，其实也不用全都list套list了，有时候你每一个类别分开写都可以，反正现在有AI了，以后要批量去删改什么的也很轻松了。

@机杼在筛选器的上限中说：

那如何判断一个条目，没有标签也没有链接也没有其他类似的项目呢

侧边栏的更多-孤儿（Orphans）标签页里就有吧，应该也是用某个筛选器实现的。

机杼

目前还不算卡，用起来的时候也影响不大。

我把上面根目录的筛选器改成了用list微件的形式。

<$list filter="[tag[wikis]]" variable="root-name">

<$transclude $variable="context-root" tiddler=<<showTiddler>> name=<<root-name>>  tid-name=<<root-name>> use-true="true" limit="15" />

</$list>

感觉能增加点筛选使用效率。

但要做条件判断就不好处理了。因为孤立条目只能是无硬式链接条目，但有些有反向嵌入的也应该要排查出来。

我尝试了一下，目前还是解决不了，就先放着了。

机杼

确实，我把list想得太抽象了。

后来我发现，即使我要判断，但因为我的节点丸和根目录是放在一起的，所以实际上我只要判断节点丸就可以了。并不需要判断那么多根目录。因为节点丸也足矣构成上下文内容。

太微中文论坛

筛选器的上限