Meta-Issue: Refactor the Navigation mechanism

[pmario]

This issue is based on discussions at:

• work on navigator.js and story.js #4178
• make navigator.js and story.js populate focus-tiddler field ... #4156
• WIP TOC refactor #3939
• navigate to tiddler above or below when cancelling, closing, deleting #4127
• ...
• and probably others which I'll link if I find them :)

[pmario]

From PR 4156

There is quite some overlapping between navigator.js and story.js atm.

It's actually worse than that because we also have some story/history helpers in wiki.js. The idea was to have a bunch of helper functions in story.js, and then slim navigator.js down to be much more readable.

It's not 100% clear to me, what should be part of story and what should be part of navigator.

Ideally, the navigator widget should be just one exposure of a box of logic that exists independently and is also used by other clients like wiki.js and hopefully future plugins.

navigator is a widget. ... So it is "end-user" visible. I think it should "abstract" the "complicated" parts away from the users. It should contain "high level" interface.

story.js is / should be accessible for plugin authors, if they need to implement "special" functions available through plugins. ... plugin authors should know, what they are doing. ... eg: populate the $:/HistoryList with additional info, that's needed to do several steps of undo. ...

I think the purpose of story.js is to package up the common, meaningful primitive operations on the story and history, particularly the ones that require policy decisions (e.g. choosing where to open a newly navigated tiddler).

So for me it should be possible to say: "close others" ... then CTRL - Z should re-open all closed tiddlers ... This functions imo can be implemented in the TBDs in story.js

I'd imagine that as part of a generic undo mechanism that steps back through changes to the tiddler store, and so wouldn't know directly about the story.js mechanism.

navigator.js on the other hand does a little bit too much atm. ... So the only function that is needed from story.js is .addToHistory() ... Some of those functions may be moved to story.js, to make navigator.js easier to read. ...

As above, I'd like to see navigator.js slimmed down: the success criteria is that it should be readable, with the method names from story.js being descriptive enough that one might not need to look at the code.

[pmario]

It's all about navigation. Navigation can be done with:

• Clicking Links
• actions-widgets
• Intercepting links with linkcatcher
• keyboard shortcuts
• plugins
• directly modify $:/HistoryList and $:/StoryList ... is hacky ... so the above methods should be used!

[pmario]

The new mechanism must be backwards compatible. .. So IMO we need tests first

[pmario]

https://tiddlywiki.com/#StartupActions may be used for testing in the browser UI

[AnthonyMuscio]

Mario,

Is there any practical what to introduce the ability for a designer to define a custom action for the "all about navigation" list above? along the same lines as Hackability of default triggers - "Buttons" #4272

If we cant have a custom action for all these navigation methods perhaps just a subset of the navigation such as from tiddler links, and link catcher? which are the primary method by which tiddlers are opened by users.

• An important factor to remember is custom widgets can always be included wrapped with a reveal or list widget to place conditions on when the action is performed.

It is my belief that should we have the ability to code conditional actions on tiddler open we would eliminate a serious limitation.

If you need to be persuaded here are some examples;

• Such actions may include starting a timer, the timer could be stopped on close using #4272,
• for large tiddlers, on open a snapshot could be triggered and displayed hiding the tiddler body, so the large tiddler avoids refresh until reopened (or refreshed) taking large time consuming renders out of the automatic refresh process and improving performance.
• On opening a project tiddler trigger the opening of related tiddlers
• On opening a Project tiddler open is own saved story list
• On opening a project task, open its project tiddler.

Regards Tony

[AnthonyMuscio]

I also think some past work also identified how to detect the change of focus between tiddlers in the story river. This would also be a suitable feature and could benefit from a custom action option as well.

[pmario]

Notes:

• The ONLY purpose of $:/StoryList tiddler is, to store the list field.
• The list field must to be a separated list of tiddler titles
• To convert a filter to a list we can use: [subfilter{a}] if a contains a filter string

[Jermolene]

Hi @pmario I'm finding this ticket hard to follow. Ideally, tickets should be bug reports or actionable proposals to change something. This seems like the middle of a discussion that is mostly somewhere else. Is the idea to group together links to related tickets? That seems like a job for tags?

[AnthonyMuscio]

This ticket is actually linked to a number of fixes so it has being quite productive.

However perhaps I should open a new issue in relation to my reply. This is very important to me.

Is there any practical what to introduce the ability for a designer to define a custom action for the "all about navigation" list above? along the same lines as Hackability of default triggers

Or has this being addressed in one of the other items?

[Jermolene]

@AnthonyMuscio the link widget doesn't support actions but the linkcatcher widget does, can you use that?

[pmario]

I do have a PR in the pipeline, which extends the possibilities of the linkcatcher, but it needs a bit more refactoring and docs updates.