reagent 2023-01-26 | Slack Archive

pez14:01:44

I have a problem with js/MediaRecorder that I can't figure out. The documentation for the stop event guarantees me that a last call to dataavailable has been made when the stop event is fired: https://developer.mozilla.org/en-US/docs/Web/API/MediaRecorder/stop_event However, I need to wait a bit for the data to actually be in the place where I store it. Pseudo code:

recorder.ondataavailable -> (fn [ev-with-chunk] conj the chunks onto my vector of data chunks)
recorder.onstop -> (fn [] read the chunks from the vector of chunks)

Often in onstop, I do not have the last chunk. Especially on my phone. I have the chunks in the re-fram app-db, but I have the same problem if I use a reagent/atom. Using reagent.core/next-tick only improves the ratio of success/failure, it still fails at times. Assuming I can trust the docs, I obviously lack understanding about something important here... I really don't like to stick a js/setTimeout in there!

p-himik14:01:27

Either the events are out of order or your data storage impl is wrong. You can confirm by logging the events and checking whether the last dataavailable sometimes happens after stop.

p-himik14:01:24

In case of re-frame, its events are queued and aren't executed immediately, so that would be easy an easy explanation. But you say you also tried using reagent/atom, and I'm not sure what could go wrong there.

pez14:01:58

Thanks! Now I seem to get away with dispatch-sync in dataavailable together with next-tick in stop. Not sure I can trust it, yet. Will log like you suggest and see what that gives.

p-himik15:01:10

You almost definitely can't trust next-tick in such cases. :)

pez15:01:31

Please elaborate slightly 😃

p-himik15:01:30

Using next-tick to help with an up-to-one-tick delay won't save you from a more-than-one-tick delay. Race conditions must not be solved with arbitrary delays.

pez17:01:21

Thanks. I guess I made the bet that these events always arrive in the order the docs say they do and then that dispatch-sync would place the the next dispatch within a tick. But that was silly, I now think I understand. I removed the next-tick from onstop and only do dispatch-sync in ondataavilable. It seems to work just as well. It still leaves me wondering about my experiment using only an r/atom, but I'm ready to disregard that. This is very tricky and tedious to sort out. Only happens on my phone.

2023-01-26

Channels