Widget error replacing DOM

[andrewgoz]

I'm working on a widget. I want the widget to process the evaluated contents of itself and replace that with computed DOM nodes. I found some code elsewhere that suggested "makeChildWidgets(),renderChildren(),parent.innerHTML":

myWidget.prototype.render = function(parent,nextSibling) {
	// Get the source text
	this.makeChildWidgets();
	this.renderChildren(parent,nextSibling);
	var text = parent.innerHTML;
	// Render it into a div
	var div = this.document.createElement("div"),
		options = {throwOnError: false};
	try {
		// div DOM stuff here processing "text"
	} catch(ex) {
		div.className = "tc-error";
		div.textContent = ex;
	}
	// Insert it into the DOM
	parent.replaceChildren(div);
	this.domNodes.push(div);
};

This is giving me what I want except for an error in removeLocalDomNodes() where the parent is apparently null.

What am I doing wrong? What should I be doing?

Thanks.

[pmario]

Do you use the latest TW master branch for your development?

---

You should avoid to write to .innerHTML. -- It's only safe to use with a lot of sanitation done to prepare the content.

[pmario]

You can have a closer look, how other widgets do it eg: the radio-button

[Jermolene]

Hi @andrewgoz it causes problems for widgets to modify the DOM nodes produced by their children. Subsequent refresh cycles might need access to the DOM nodes, and raise an error because they no longer exist.

An alternate pattern is used by the core Dynannotate widget to replace or augment the DOM nodes produced by child widgets: the child DOM nodes are rendered to a DIV that can be hidden and shown as required.

[andrewgoz]

So, the problem was where I was calling

parent.replaceChildren(div);

I replaced it with:

this.removeChildDomNodes();
parent.insertBefore(div,nextSibling);

and the error has gone away. My plans for world domination widget development can proceed...

Unless there is a problem with this I'm not seeing?

[Jermolene]

Hi @andrewgoz the problems will occur if the widget subsequently invokes this.refreshChildren(); those child nodes in the widget tree will have had their DOM nodes disturbed, and so won't behave as expected.

What are you trying to accomplish?

[andrewgoz]

Last year I did a plugin for Google Charts, which is always online. I've been looking at various offline chart libraries and trying to work out which one will do what I want and is within my capabilities of developing a suitable TiddlyWiki plugin.

So far the front runner is ApexCharts (https://www.apexcharts.com/). That library needs an "options" data structure. I've been working on how to build that inside the contents of the widget, so it looks like:

<$myWidget>
{
  // ... options properties here ...
}
</$myWidget>

Importantly, I want to be able to run <$list> macros in there so that chart data can be built from tiddlers.

I have just uploaded my work in progress to: http://www.scss.com.au/family/andrew/tiddlywiki/

There's a demo chart in the plugin readme, that doesn't do anything fancy like running a <$list>, although I've got the <$list> working on a private wiki. I'll see what I can do when I get home from work tonight.

Also, I've found that doing parent.innerHTML or parent.textContent was picking up text in siblings adjacent to the widget, not just the children inside the widget. Refer to the code in the OP. Changing that to this.findFirstDomNode().wholeText appears to be getting the correct text.

I often think that my TiddlyWiki development process involves throwing random things into the code and seeing what works...

[arunnbabu81]

@andrewgoz I do really like your Google charts implementation. But I was hesitant to include it in my wikis since it was online only charts. So I am eagerly waiting for your offline implementation of Apex charts. Thank you for all you our good works.

[andrewgoz]

http://www.scss.com.au/family/andrew/tiddlywiki/ has now been updated with my latest plugin and some demo charts where the date is obtained from selected tiddlers.

This is apparently working just fine, only throwing errors when the chart configuration structure is incorrect in some way. There doesn't appear to be a lot I can do about that.

Thanks everyone for your contributions. I appreciate your time and efforts.

[Jermolene]

Hi @andrewgoz you might be interested in the <$data> widget that is used by the innerwiki plugin and the testcase widget. It provides a generic way to construct structured data that can then be ingested by another widget.

[andrewgoz]

Thanks, but the issues I originally had related to managing the TiddlyWiki DOM nodes, and once I found the correct way was to call this.removeChildDomNodes() it all came good.

Then, the code required to get the chart data is more-or-less just this.findFirstDomNode().wholeText. To keep things as simple as possible I decided the best way is to build the options data structure ApexCharts requires directly from text. I feel anything else would require me to implement what would end up duplicating the ApexCharts parsing code, and need regular updating as ApexCharts changes.

I looked at the <$data> widget, but it doesn't seem to be useful in this case.

What I've done allows people to copy-and-paste example chart configurations from the ApexCharts examples and it will work. Then using TiddlyWiki widgets like <$list> to build up the ApexCharts series data is reasonably straightforward and intuitive.