Dynaview - Make it work for all scrollables and allow saving the topmost tiddler

[BurningTreeC]

Hello there,

I wonder if we can make the dynaview plugin work so that it doesn't only listen on the window for scroll events but on all scrollable elements

Further, a configuration option would be great, which allows saving the topmost tiddler title in a state tiddler if set to yes

What do you think?

[Jermolene]

What do you think?

Great idea, would you be interested in working on that?

Alternatively, we could explore a different approach using intersection observers. I think that would require us to move to a widget-based architecture, where there would be a <$dynaview> widget that sets up an intersection observer on its content, and we wouldn't do all the DOM attribute-based communication.

[saqimtiaz]

@Jermolene looks like we posted simultaneously.
+1 for leveraging intersection observers.

[saqimtiaz]

Two things that might be useful to consider if we work on this:

• with dynaview I managed to set it up with my Streams plugin so that it wasn't required but was automatically used if present. This required a fair bit of wrangling with the templates. It would be good if we could keep such use cases in mind in the widget-based approach and see if we can make them easier to implement.
• one of the issues that I ran into (and this may only have been in my modified version) was that it was only effective for the first display of a tiddler. Once it had been rendered the first time, the associated state tiddler already exists. So if the tiddler was closed and then re-opened somewhere off screen, it would still be rendered.

[BurningTreeC]

What do you think?

Great idea, would you be interested in working on that?

Alternatively, we could explore a different approach using intersection observers. I think that would require us to move to a widget-based architecture, where there would be a <$dynaview> widget that sets up an intersection observer on its content, and we wouldn't do all the DOM attribute-based communication.

@Jermolene, yes I'd be interested in working on that

[saqimtiaz]

I wonder if we can make the dynaview plugin work so that it doesn't only listen on the window for scroll events but on all scrollable elements

This is a good idea. I wrote my own version of dynaview (that I call dynascroll) for my Notation editor. The idea was always to eventually modify the original to be more flexible. I've also experimented with using intersection observer to implement the same functionality, however there is no IE support for it.

[BurningTreeC]

Thanks @saqimtiaz , there's a polyfill for the intersection observer if we want to implement it that way

[BurningTreeC]

@Jermolene @saqimtiaz ,

if we create such a <$dynaview> widget, how do we listen on the window for scroll events?

[saqimtiaz]

The great thing about intersection observer is that we don't need to listen to scroll events.

Have a look at the examples of code given here: https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API

[pmario]

IMO there is a reason, why "intersection observer" exists. ... Because we avoid to listen on scroll events if possible. This event fires a million times and has the potential to slow down the whole UI and it creates so called "scroll jank".

Since the browser doesn't know if the event handler stops propagation it has to wait until the handler is finished. If the handler is slow this causes a visual "jank"

[Jermolene]

IMO there is a reason, why "intersection observer" exists. ... Because we avoid to listen on scroll events if possible. This event fires a million times and has the potential to slow down the whole UI and it creates so called "scroll jank".

Since the browser doesn't know if the event handler stops propagation it has to wait until the handler is finished. If the handler is slow this causes a visual "jank"

The original Dynaview didn't use intersection observer because it wasn't widely implemented at the time. Using scroll events really isn't so bad; the necessary techniques are well understood and work reliably.

[BurningTreeC]

@Jermolene @saqimtiaz @pmario,

would such a <$dynaview> widget be placed in the $:/core/ui/PageTemplate tiddler (like, globally) or in the $:/core/ui/ViewTemplate and $:/core/ui/EditTemplate tiddlers, which, for me, would make more sense?

[Jermolene]

Hi @BurningTreeC the <$dynaview> widget would be wrapped around any individual content items that need to be rendered dynamically. I wouldn't have thought it would be included in any of the core templates by default.

[BurningTreeC]

Thanks @Jermolene, yes I understand that it wouldn't be included in any core template by default, I'm just trying to get the logic

[BurningTreeC]

@Jermolene , I'm experimenting with a widget that uses the IntersectionObserver right now and I think that it can work out

[saqimtiaz]

@BurningTreeC it has been a while since I prototyped something similar with IntersectionObserver, but as I recall I had a startup script setting up an IntersectionObserver for the document viewport with a reference saved as $tw.rootIntersectioObserver. Then with a widget like <$dynaview/>, in it's render() method you would create its DOM node (domNode) and then call $tw.rootIntersectionObserver.observe(domNode). So one intersection observer, many widgets being observed.

[BurningTreeC]

@saqimtiaz,

@BurningTreeC it has been a while since I prototyped something similar with IntersectionObserver, but as I recall I had a startup script setting up an IntersectionObserver for the document viewport with a reference saved as $tw.rootIntersectioObserver. Then with a widget like <$dynaview/>, in it's render() method you would create its DOM node (domNode) and then call $tw.rootIntersectionObserver.observe(domNode). So one intersection observer, many widgets being observed.

That sounds reasonable 👍

[pmario]

After that I thought we could get the logic right

OK. I see. ...

[BurningTreeC]

@saqimtiaz, the problem is that the intersection observer should be variable to detect intersections with other roots, too

[pmario]

@saqimtiaz, the problem is that the intersection observer should be variable to detect intersections with other roots, too

Then we will need to create an observer-manager with "register" functionality. EG in the sidebar when we switch tabs, the dom-structure for the "hidden" tabs are destroyed. ... Prior to hiding the elements we will need to ask the manger if an observer is active for this root and call the disconnect() function. When the tab will get visible again, the observer has to be instantiated again. IMO a simple lookup table should be enough.

[pmario]

What I had expected for the story river / classic storyview is the following:

• If a tc-tiddler-frame gets visible on the screen it will be rendered.
• If a tiddler-frame leaves the viewport it will not be re-rendered anymore, because it can't be seen.
• If a tiddler title reaches eg: the upper area of the current browser viewport, it becomes the top-most tiddler
  • "the upper area" can be defined by the user eg: 20%
  • If the title is below the top 20% of the area, that tiddler at the top is the top-most tiddler, even if the title can't be seen anymore.

That's basically it for the StoryRiver.

For long lists in the right sidebar it is similar, but it wouldn't be the tc-tiddler-frame that will be watched. It will be tc-menu-list-item

[BurningTreeC]

👍 @pmario