may be somebody knows how this plugin works an can write new version for 5.1.2
to disable refresh (or make refresh all lists on special button click) all $list and {{{[…[…]]}}}
it works a little faster with “refresh off”, but not very fast. How can we see what processes make Tiddlywiki work slow? How can I make JavaScript speed test?
You should consider an alternative to using the zoomin storyview. With the zoomin storyview, when you navigate to a new tiddler, the previous tiddlers are still rendered and refreshed.
@Siniy-Kit another approach is to take a “html” snapshot of a tiddler in html and display that rather than rendering the whole tiddlers and lists therein, again, each time the tiddler is opened.
Attached is my snapshot tool that illustrates this, but expect you may need to test and customise for your use. Please try on tiddlywiki.com before installing in your wiki.
@Siniy-Kit when I follow your second link I only see 4 columns with short lists Information/Catalogue/Our address and Call us. So I can see a long list with a view to using the shapshot tool.
This snapshot approach will not stop all list updates, only those in a tiddler (or part there of) with a snapshot.
I assume this is a single file wiki, not node?
I think there would be value getting some metrics to determine if what you ask for is an actual performance bottleneck before looking for a solution.
I am not sure if this approach is going to help you, however I have a hunch it can.
A few thoughts;
The snapshot (by the Wiki Author) takes a copy the the HTML rendered for a particular tiddler and stores it in another tiddler. When viewing the original tiddler the “pre-rendered” HTML is displayed rather than its body, this means the list widget need not be rendered at “run time”.
Theoretically this allows you to pre-render and save the result for visitors, however the tiddler view will/may not respond to changes unless another snapshot is generated.
In the case of an online shop I am not sure how a html snapshot will work with interactive products eg add to cart component. However it works a bit like a static html tiddler while still being inside the tiddlywiki.
In TiddlyWiki 5.2.x the new cascade mechanism for the view templates may help implement this is a smart way. The html snapshot can be rendered without any macros and other code be included and render time.
Ideas;
The concept of pre-rendering tiddlers makes use of the standard rendering through the body template. However it is possible to have an alternate body template designed to support pre-rendering of tiddlers in particular ways, this may include pulling content such as pre-rendered lists but include other interactive content.
The question is will this help meet your objectives to enhance performance?
Perhaps a mechanism to transclude html snapshot’s as parts of a tiddler makes sense?
Pre-rendering could actually pull html from the file system, which would allow it to be externalised and cached separately whilst existing within the interactive tiddlywiki.
I can imagine the idea of navigating to snapshot tiddlers by default with only the designer being in a position to rerender the tiddlers snapshot using the wikitext and $list widgets etc… If a tiddler need not be re-rendered on the live site the source tiddler could be removed from the published wiki.
I hope I am helping, not confusing you, but it seems this is an area that has a number of innovative possibilities.
@Siniy-Kit I can drop my package on your site and it seems ready to work, but as a rule it takes a snapshot of the result of rendering the body, on the link you showed me most of the content is rendered via some other method such as the view template.
I think it could be modified to capture the body and result after applying the view template, but I admit I struggle with the other language on the site.
Here is another package of two buttons I use to open a new window with the full rendering, which demonstrates what could be done with the snapshot tool, by opening the tiddler in a window including with the view template applied.
it is empty, because my tiddlers text field is emty. And all data to it is put by template Обувь и всё для обуви — Уход за обувью
with special tag $:/tags/ViewTemplate
so all content is not in tiddler-body and there is nothing to snapshot…
I’m not in a position to try this right now, but I was wondering if using the select widget for selecting a tiddler from a large list would have any better performance than selecting from a displayed list. Just curious.
I managed to do a little testing today with a displayed list versus the select widget and found no significant performance difference. I was expecting this to some degree since the same list is being generated. I was curious to see if the fact that the list wasn’t always displayed in the select widget played a performance role. Answered.
I just wanted to point out people are using the new event catcher widget to reduce the complexity of the HTML generated using the list widget. Apparently it has performance advantages.
Perhaps this could help?
Also consider reworking the code so when you click on a list item it updates something that is not visible and does not cause a need to refresh the tiddler containing the list. For example add the item to the cart, but don’t indicate it is in the cart in the original list.
Attached is a very quick experiment at implementing a new layout for performance testing purposes that avoids the need for the zoomin view, it also removes the sidebar. Please try this on your site and report back if it helps with performance.
Import all the tiddlers
Ctrl+Shift+L and choose the single tiddler layout.
You could also try combining this with the refresh disabling widget, setting a filter such that the refresh is only disabled when single tiddler layout is active.