[IDEA] create a "change-catcher" widget, which allows us to create wikitext-actions based on the core change event

[pmario]

Just a reminder, so it is not forgotten.

See: https://talk.tiddlywiki.org/t/idea-cascades-for-save-button-close-button-edit-button-etc/9327/14?u=pmario

and my response: https://talk.tiddlywiki.org/t/idea-cascades-for-save-button-close-button-edit-button-etc/9327/15?u=pmario

But this means that my idea of lifecycle events no longer sounds particularly far-fetched. There’s a mechanism in the underlying JS, which we should (presumably?) be able to expose to wikitext, to tap into certain lifecycle events.

The “change” event is activated, whenever a tiddler changes in the tiddler store. It activates all event-listeners, that are registered to listen to it. Usually the change event triggers the widgets “refresh” mechanism. Within widgets, there is a lot of logic going on, to only trigger a child-refresh, if it is really needed. So if widget parameters are not “connected” to the tiddlers that are changed, there is no refresh needed. …

If we expose the change event to eg: wikitext actions, it’s very likely that users will start to modify tiddler content based on this event. That will cause a “change” event, which triggers the actions, which causes a “change” event, which triggers the actions, which causes … you get the idea … The perfect environment to brick the wiki and loose data.

So we basically would need a <$change-catcher widget, which must define a filter parameter that limits the tiddlers, the catcher is bound to. So we can make it safer to use. The change-catcher widget would only be active, if it is visible and imo it should ignore its body text. So it would look like <$change-catcher filter="[tag[x]]" actions=<<actions>>/>

[Jermolene]

Hi @pmario from the original context, it really sounds like the underlying problem that people are trying to solve is forcing refresh of content that doesn't automatically refresh. I suspect that we'd be better off exploring fixes for that specific problem than opening this particular can of worms: besides the usability issues you correctly identified, there are also quite a few implementation issues. For example, this implies that a widget could listen to tiddler store events, which would mean cleaning up the listener when the widget is removed, which is not currently supported. Of course, widgets already indirectly get passed change events in the shape of the refresh method, which takes us back to my suggestion that we fix the refresh process.

It seems much simpler to have something like a new widget that always re-renders its content at every refresh.

[CodaCodr]

Unless I'm missing something about the proposal...

I monitor change events using $eventcatcher. Works fine as is.

Is there a nuance here I'm not aware of?

[pmario]

I monitor change events using $eventcatcher. Works fine as is.

Do you have a code example for this one? I thought the eventcatcher can only catch events initiated by users.

The idea should make the core wiki "change-event" available to wikitext. -- If possible -- Some experiments would be needed.

[CodaCodr]

Do you have a code example for this one? I thought the eventcatcher can only catch events initiated by users.

Ah, that's the nuance I was missing. As you were ;)

[pmario]

@Jermolene -- Can you make this issue a Discussion. So I do not need to close it and give us more time to think about it.