I do not have a minimal failure case repo yet.
After porting over a bunch of Brr.Fut.t code to js_of_ocaml-lwt, it appears the pointerdown/click handlers on all of my incr_dom/bonsai examples have broken. Keyboard still works. Just pointerdown/click event handlers.
I believe incremental/incr_dom/bonsai uses async, not lwt.
Are there known problems when lwt interacts with incremental/incr_dom/bonsai ?
Not really an answer, but I’m curious how you are managing to use Fut and Lwt with bonsai effect handlers…as they all work with
Effect (eg the list of handlers here here). (I thought) the main way to get an Effect from a non-bonsai-ish thing was with
Effect.of_deffered_fun which works only with functions returning deferred values. (Or, with
(Or by broken do you mean they no longer compile?)
I’ve successfully used LWT with Bonsai before in Tutorial: Full-Stack Web Dev in OCaml w/ Dream, Bonsai, and GraphQL, so it’s definitely possible. Even if it’s not a minimal failure case, do you think you could share some code?
I’m not using Fut anymore. Brr deps have been rewritten in jsoo, jsoo_lwt, bonsai.
The reason I have Lwt at all is 2.1 I have some stuff during program initialization i want to fetch via XmlHTTPRequest, and 2.2 some messageChannel/Port I need to setup for iframe-iframe communication.
So I have a
'a Lwt.t which does all that setup, which then gets passed to Bonsai. [.though right now, it’s not even being passed to Bonsai; I’m just running Bonsai afterwards ]
Everything compiles fine. Most things even runs fine. Keyboard inputs (j/k) works tine in the ts-gui-table-partial-render for moving up/down. Mouse up/down wheel also works.
Things that don’t work: mouse clicking on multi-elem-selection boxes (from bonsai/forms example), mouse clicking (from bonsai/drag-drop-example), mouse clicking (from my own examples). For whatever reason, mousepointerdown events are NOT triggering.
Yeah, sorry, it’s giant mess at the moment. I have one dune project that has all my OCaml experiments (code snippets from manuals, from bonsai, actual work, from other stuff); I need to refactor a bit before having something worth showing.
- Currently I’m using this as an excuse to learn async; and see if switching lwt → async fixes it.
The good news is the bug is deterministic. After switching from js_of_ocaml-lwt and promise_jsoo_lwt to async_js and async_kernel, the bug remains the same.
In Chrome dev console, when I click on element → event listeners, I see handlers for:
Sorry for false claims.
Turned out to have nothing to do with lwt/async. It was a CSS issue.