The only other (very minor) problems I had were:
1. Wanting to refer back to an element in a callback, for animations
or form values. There is some code like this:
let item_ref = ref None in
let callback ev = ... (use !item_ref) ... in
let item = a ~a:[a_onclick callback] [...] in
item_ref := Some item;
This is the typical example where you want to use Lwt_js_events, which
avoids the recursion (and the reference)
let item = a [ ... ] in
let dom_item = Tyxml_js.To_dom.of_a item in
Lwt.async (fun () -> Lwt_js_events.clicks dom_item (fun _ev
_handler -> .... use dom_item/item ...))
We could implement Lwt_js_event (and a mutation module similar to
Eliom_content.Manip[2]) directly on Tyxml_js's nodes, but it's not done
right now.
And it would need more functors...
[2]: http://ocsigen.org/eliom/4.1/api/client/Eliom_content.Html5.Manip
2. Some workarounds were needed for MSIE. e.g.
https://github.com/talex5/cuekeeper/blob/90a12e71834ae10416e0ec86ce15408ec25d33e6/js/ck_template.ml#L27
For the GC issues, Lwt_react[1] helps a bit, in particular E.keep and
S.keep. It basically implements your "global sink" idea. Doesn't solve the
space leaks in javascript, though. Lwt_react in general is a very nice
improvement over React when used in conjunction with Lwt.
Yes, but the global sink is only useful if unused handlers get freed.
Otherwise, it just stops things getting GC'd at all.
Well, here is the implementation of keep:
let keeped = ref []
let keep e = keeped := map ignore e :: !keeped
(that's React's ignore)
So you should be able to have several "keepers" like that, and the
lifetime of signals would be the lifetime of the keeper.
You didn't seem to use Lwt_js_events (or just didn't talked about it) in
jsoo, is there a reason ?
Handling events seemed simple enough with a_onclick attributes. I only
used Lwt_js_events for the "async" method. Would it have helped?
It avoids recursion issues (see earlier) and occasionally offer very
interesting control over the buffering and the sequentiality of events.
You can also do complex stuff very easily, like receive event A, wait
for event B, then on receiving B, start waiting for A again.
That's quite useful sometimes.
_______________________________________________
MirageOS-devel mailing list
[email protected]
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
