Save tiddly text without updating DOM?

109 views
Skip to first unread message

Matt DeMoss

unread,
Sep 19, 2019, 5:28:36 PM9/19/19
to TiddlyWikiDev
Is there a way to setText on an open tiddler without causing the tiddler's DOM to be updated? (As in cases where the DOM has already been updated by script.)

TonyM

unread,
Sep 19, 2019, 9:31:37 PM9/19/19
to TiddlyWikiDev
Matt,

I am no expert on this but if the tiddler is folded or has a field hide-body=yes
the tiddlers DOM will not be updated until it's visible?

But of course if you use the above methods the tiddlers content will not be visible.

For very large and complex tiddlers, I have being interested in creating a snapshot utility that evaluates the tiddler and stores it in a hidden tiddler (In a HTML output form for example), hides the body and displays instead the snapshot. This would make the snapshot visible, and there would be no automatic refresh. You could then either regenerate the snapshot on demand or return to the normal view when needed.

This refresh suppression solution would be available to all designers and not embedded in a specific javascript plugin. Point in time snapshots and possible comparisons of snapshots and or the interactive results may also be possible. eg; highlight the changes that occured in a very large tiddler.

Regards
Tony

Matt DeMoss

unread,
Sep 20, 2019, 11:23:26 AM9/20/19
to tiddly...@googlegroups.com
The first thing I tried was removing the data-tiddler-title attribute from the parent div, saving the text, and then putting the attribute back. This doesn't work, so I assume TW must be keeping references.

In my case I want only those DOM updates to be suspended for a single setText call where I can guarantee that the DOM already reflects the current state. I'd be worried about interfering with other plugins otherwise.

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywikidev/DtJ2jiel03I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywikide...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/5c2f597c-4807-4ba2-adcc-48b6fd65ffea%40googlegroups.com.

Jeremy Ruston

unread,
Sep 20, 2019, 11:27:25 AM9/20/19
to TiddlyWikiDev
Hi Matt

Can you explain a bit more context of what you’re trying to do, and what you’ve tried so far?

It sounds like you might be integrating a third party script with TiddlyWiki. The best approach depends on the type of script. The core plugin library includes many examples.

Best wishes

Jeremy

You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywikide...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/CAAJxWYS%2B3-LjQYvjaPCQyzJ%2BjQNkChSYvpy2nrexo_c7DF_gRw%40mail.gmail.com.

Matt DeMoss

unread,
Sep 20, 2019, 3:09:00 PM9/20/19
to tiddly...@googlegroups.com
You can see an example in updateDoneStatus here:
https://github.com/mdemoss/TW5-TimeTodo/blob/master/js/todoElem.js#L107  

This is a custom element responding to an event from inside its shadow DOM. The custom element would otherwise be responsible for keeping its appearance up to date with its state.

When setText is called all the objects get replaced with new ones that look mostly the same. This actually mostly okay, but I suspect it may be hurting performance on mobile Safari and my approach to keeping focus in the new item text box after setText is necessarily a bit hacky:

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/6459A00E-215A-493C-A691-D86069C2D53D%40gmail.com.

Jeremy Ruston

unread,
Sep 22, 2019, 11:58:23 AM9/22/19
to tiddly...@googlegroups.com
Hi Matt

You can see an example in updateDoneStatus here:
https://github.com/mdemoss/TW5-TimeTodo/blob/master/js/todoElem.js#L107  

Ah, yes indeed. It’s an interesting project. When I started work on TW5 custom elements were just being introduced by browsers and I investigated using them. The obstacle back then was patchy browser support but now is a much better time to investigate.

I note that your custom elements have knowledge of the tiddler store etc. Is the idea that people would be able to use custom elements within tiddlers instead of the usual widgets? Or that TW5 widgets would generate the custom elements as part of their implementation?

This is a custom element responding to an event from inside its shadow DOM. The custom element would otherwise be responsible for keeping its appearance up to date with its state.

When setText is called all the objects get replaced with new ones that look mostly the same. This actually mostly okay, but I suspect it may be hurting performance on mobile Safari and my approach to keeping focus in the new item text box after setText is necessarily a bit hacky:

The trouble is that that is how TiddlyWiki5 works: the user interface is generated reactively from the data store, and any update to the data store will update the user interface. The corollary that you may be falling foul of is that the *only* way to change the UI is to update the data store.

Best wishes

Jeremy

Matt DeMoss

unread,
Sep 28, 2019, 2:18:46 PM9/28/19
to TiddlyWikiDev
I note that your custom elements have knowledge of the tiddler store etc. Is the idea that people would be able to use custom elements within tiddlers instead of the usual widgets? Or that TW5 widgets would generate the custom elements as part of their implementation?

I initially I planned to have a TW5 widget to generate the custom element; TW5-Checklist was my inspiration, and I thought I would adopt a modified version of the square bracket syntax used there. However, when I began to think in detail about extending that syntax for all the state I need to store, I saw it would take time and trouble and probably not be much better than HTML. Using the custom element directly, I get serialization and deserialization "for free."

I knew I wanted to mock-up my design in HTML and to use web templating (doT js in this case) to render the view. I looked for a way to do this with widgets, but the examples I found render the view by manipulating DOM objects directly.

The trouble is that that is how TiddlyWiki5 works: the user interface is generated reactively from the data store, and any update to the data store will update the user interface. The corollary that you may be falling foul of is that the *only* way to change the UI is to update the data store.

I wanted to mimic the way TW5-Checklist works and keep the necessary state all together in one tiddler and somewhat human-readable. Keeping the humanized (by moment.js) duration strings and is-done status up to date requires making updates to the UI on a timer, but no stored state is changed during those updates.


I can't say I completely understand, but I think I might be able to avoid the performance penalty for refreshing the containing tiddler's DOM if I: 1) keep the state in an outside tiddler, 2) refactor as a widget, and 3) define the view as an object instead of a web template.
 
Hi Matt

To unsubscribe from this group and all its topics, send an email to tiddly...@googlegroups.com.

-- 
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddly...@googlegroups.com.

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywikidev/DtJ2jiel03I/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddly...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddly...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages