Clojurians Log v2
clojurescript 2026-04-16
Can anyone help me understand why code in an async/go block does not execute if called from a "pagehide" eventListener? I'm trying to fire a method that writes to localStorage when the page is refreshed. Previously I was listening for the the "beforeunload" event but I've recently learned that this is not well supported on mobile I've been experimenting with "pagehide" and even "visibilitychange" What I'm seeing is that when a function is triggered by either one of these events, specifically when the page is refreshed any code that is inside an async/go block does not appear to be triggered but it works if I call the code directly I suspect that the async/go block is sending code into a new thread but the refreshing page either doesn't create a new thread or instantly destroys it My follow up would be, is there a way to get this to work, or am I expecting too much of the Page Lifecycle...?
From https://developer.chrome.com/docs/web-platform/page-lifecycle-api#state-terminated:
> A page is in the terminated state once it has started being unloaded and cleared from memory by the browser. No https://html.spec.whatwg.org/multipage/webappapis.html#queue-a-task can start in this state, and in-progress tasks may be killed if they run too long.
Using a go block attempts to start a new task.
BTW, according to MDN pagehide is also not a reliable event at all.
> async/go block is sending code into a new thread
Kinda, as there are no separate threads in browsers (apart from web workers and some other things, not applicable here).
> is there a way to get this to work
Why do you need for that code to be async in the first place? Local storage is a sync thing, it doesn't require you going async.
Thanks for the quick response My motivation is that I'm using an existing package to handle some of the LocalStorage functions and that package makes all the calls within async/go In order to do this fully "sync" I've had to reproduce some of the package code to call it directly That appears to be working. It would be cleaner to use the package directly but from what you say, for my context, I'm going to have to stick with the workaround
That package made some poor design choices. :) Async is posinous.
...interesting Async not useful as an interop for handling promises then? or would you recommend something else
By "async" I mean just that, in general - not core.async specifically.
Promises are async by themselves. core.async can be useful when working with promises, but I prefer to avoid it if the project doesn't use it already.
By "poor design choices" I meant that the library made sync code into async.
ok, thank you for the clarification