With compose-html, how do I observe scroll offset?...

# compose-web

[ursus]

With compose-html, how do I observe scroll offset?

(i'm accepting kobweb extensions as well 😀)

[Chrimaeon]

https://developer.mozilla.org/en-US/docs/Web/API/Document/scroll_event

[ursus]

how do you suggest I expose that? wrap it into a Flow and then collectAsState?

[Chrimaeon]

Yes. Create the callback in a DisposableEffect so you can unregistered when the composable leaves the composition.

[ursus]

thanks

[Chrimaeon]

something like this

var distance by remember { mutableDoubleStateOf(0.0) }
DisposableEffect(window) {
        val scrollListener =
            EventListener {
                distance = window.scrollY
            }
        window.addEventListener("scroll", scrollListener)

        onDispose {
            window.removeEventListener("scroll", scrollListener)
        }
}

[ursus]

wont wrapping into a Flow be more idiomatic?

[Chrimaeon]

not in “pure” compose world. there you work with states.

[ursus]

say you wanted to share this bit, how'd you encapsulate it?

[Chrimaeon]

depends on what you want to do with the scroll event.

[ursus]

print it

im just wondering what the abstraction should be if not fllw

one doesnt usually need to wrap a 1st party api with DisposableEffect in order to observe some property

[Chrimaeon]

one doesnt usually need to wrap a 1st party api with DisposableEffect in order to observe some property

well. thats the purpose of side effects to make “non compose world” work with compose.

[ursus]

in android scorllable column it is I believe scrollState.scrollY , so just a property being read

[ursus]

so therefore I'd expect api shape of window.scrollY

[Chrimaeon]

thats not how compose html works. there are no API’s for anything outside compose. It’s only a modified compose runtime that creates dom elements instead if drawing to a canvas.

[ursus]

I know, i'm just thinking about the idiomatic api shape for your snippet, if it were provided by the library

[ursus]

since you told me to skip the Flow middleman, which youre right about

[Chrimaeon]

I see, no clue - never thought of how to wrap this in a library.

[S.]

realistically you would only wrap this in a nicer api for bigger and specific components where internally you'd still use the code above. there is quite a big number of different event types which can be applied to all kinds of html elements, with different options and uses

[ursus]

@Composable
fun rememberWindowScrollY(): State<Double> {
    val scrollY = remember { mutableStateOf(window.scrollY) }

    DisposableEffect(Unit) {
        val listener: (org.w3c.dom.events.Event) -> Unit = {
            scrollY.value = window.scrollY
        }
        window.addEventListener("scroll", listener)
        onDispose { window.removeEventListener("scroll", listener) }
    }

    return scrollY
}

like this? i.e. just to hide the mutable state inside and return it?

[S.]

if you need to reuse this rather often then I guess that's fine. but what's your actual use case for listening to page scrolling? I find that I rarely need it and it's also one of the more expensive events

[ursus]

to apply some transformations to elements based on scroll (translate header away)

[S.]

often what you actually want is the intersection observer https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API rather than calculating something based on scroll offsets

[ursus]

no I just want to slide away top bar as user scrolls down

[ursus]

okay ill check that out, im complete noob i dont knlw any web apis, thanks

[S.]

well for your case the scroll event is indeed the best option

[ursus]

if I might

whats the scrope of a plain remember here? does it survive refreshes?

[S.]

nope. for that you need to use session or local storage

[ursus]

hmm but I guess scroll offset would be reset as well, right?

[S.]

your function would reset but window.scrollY itself does not. it's always the exact viewport offset

[S.]

so you can initially call window.scrollY to check the current position. it's just not possible to observe it's value outside of loops or event listeners

[ursus]

stupid question, but whats is a refresh technically, when one hits the refresh button right? not when i close and then reopen the tab

[S.]

good question. when you close and reopen a tab, your browser might scroll by itself to your last position while a refresh usually is instant

[S.]

but both will call your main function, I think you can regard both as a refresh. it's basically also the same as visiting for the first time, except that the browser remembers your scroll position (also not always though)