Which code implement "reconciliation" in tw5?

[linonetwo]

What is reconciliation?

reconciliation
The algorithm React uses to diff one tree with another to determine which parts need to be changed.
update
A change in the data used to render a React app. Usually the result of setState. Eventually results in a re-render.

I thought tw's v-dom has this feature, but in my plugins, I directly create new DOM element in the render method, and append them to the parentElement provided by tw5.

After reading need-for-speed thread in the talk forum, I start rethinking if I was doing wrong.

Or maybe tw5 just doesn't have this comparison? Thus every DOM gets updated when a tiddler (even a draft) changes. Maybe I have to read the code to find out.

[Jermolene]

TiddlyWiki doesn't use a virtual DOM. Instead, each widget is responsible for refreshing itself and any attached DOM nodes when there have been changes to the tiddler store. In other words, we refer to "reconciliation" as "refreshing".

[linonetwo]

Thanks, this is reasonable, because Widgets are not "pure functions", so we can't predict the output from its input. (If so, we can easily add some performance improvements).

Basically, "attribute" + "state" => output , we can know whether a widget's attributes changed, but currently many widgets put state on this, for example:

this.list = this.getTiddlerList();

so we can't know if it is changed, so we can't do the same thing as react.

[pmario]

The state of TW is kept in tiddlers. So if tiddlers are changed, the wiki-store $tw.wiki starts a .dispatchEvent("change",changes) event.. Every element, that has registered an eventHandler with .wiki.addEventListener("change",function()) is notified.

See:

TiddlyWiki5/core/modules/wiki.js

Line 145 in a05302d

exports.enqueueTiddlerEvent = function(title,isDeleted) {

The widget "refresh" mechanism is started with a "change" event. Some "early" eventListeners are registered at startup-time in render.js

TiddlyWiki5/core/modules/startup/render.js

Lines 30 to 40 in a05302d

	exports.startup = function() {
	// Set up the title
	$tw.titleWidgetNode = $tw.wiki.makeTranscludeWidget(PAGE_TITLE_TITLE,{document: $tw.fakeDocument, parseAsInline: true});
	$tw.titleContainer = $tw.fakeDocument.createElement("div");
	$tw.titleWidgetNode.render($tw.titleContainer,null);
	document.title = $tw.titleContainer.textContent;
	$tw.wiki.addEventListener("change",function(changes) {
	if($tw.titleWidgetNode.refresh(changes,$tw.titleContainer,null)) {
	document.title = $tw.titleContainer.textContent;
	}
	});

The first event that is triggered there is the one registered by $tw.titleWidgetNode(), which sets the document.title of the browser window. So if you change the content of the $:/SiteTitle in the ControlPanel, the browser document.title is updated immediately. So this info can be seen in the browser tabs.

This event is easy to follow. Open $:/core/wiki/title it contains 2 transclusions and 1 list-widget

{{$:/SiteTitle}}
<$list filter="[{$:/SiteSubtitle}trim[]minlength[1]]" variable="ignore">
&#32;---&#32;{{$:/SiteSubtitle}}
</$list>

Since the $:/SiteSubtitle is not changed, the subtitle transclusion widget should not be redrawn if you only change the $:/SiteTitle.

This can easily be tested with eg: Edge or Chrome Dev-Console -> Rendering tab -> Paint flashing enabled.

The transclusion .refresh() code can be found at:

TiddlyWiki5/core/modules/widgets/transclude.js

Line 406 in a05302d

TranscludeWidget.prototype.refresh = function(changedTiddlers) {

There are several other elements that are updated:

• Title of this TiddlyWiki - link, because it contains a link to the $:/SiteTitle tiddler. The link-widget refresh mechanism checks if there have been changes to one of it's attributes. The to-attribute <$link to="$:/SiteTitle"><<lingo Title/Prompt>></$link>

So if you have a look to the link-widget code:

TiddlyWiki5/core/modules/widgets/link.js

Line 208 in a05302d

LinkWidget.prototype.refresh = function(changedTiddlers) {

• You can see, which widget-attributes are checked for a change that will cause the link-widget to destroy and re-render itself with this.refreshSelf();

• return this.refreshChildren(changedTiddlers); will always be called by every widget to inform their children to also check their refresh-state.

---

At Talk you ask

1. Why every DOM get updated when a tiddler (even a draft) changes? ..

As you see above .. not every DOM element is redrawn, only widgets where related widget-attributes have been changed. So it's highly selective. Those changes are calculated in the .render() function with: this.computeAttributes(); which is basically always one the first lines in any widget render() function.

IMO It should be similar in your own .render() functions to be performant.

Hope that makes sense.
-m

[pmario]

@linonetwo you wrote

#7558 (reply in thread)

this.list = this.getTiddlerList();

so we can't know if it is changed, so we can't do the same thing as react.

It would be interesting to see the context. As I wrote above, TW state should always be kept in tiddlers. That's the only way to know when to refresh. ... I think there is a high chance, that the code above is there for easy use of the this.list for "local functions" which need access to the list in a closure.

[pmario]

I think I found the important context for the internal state. And the this.list is used very often in the code so it would not make sense to recreate the list everytime the values are needed.

TiddlyWiki5/core/modules/widgets/list.js

Lines 199 to 202 in a05302d

	ListWidget.prototype.handleListChanges = function(changedTiddlers) {
	// Get the new list
	var prevList = this.list;
	this.list = this.getTiddlerList();