Fork me on GitHub
Oliver George02:05:28

Are there any recommendations for working with async API's as coeffects? Specific use case is where an event handler needs data which lives behind an async api.

Oliver George02:05:53

I think the correct but clunky approach is to make sure the data is in app-db before the event handler is called.

Oliver George03:05:31

Incidentally @mikethompson it seems to me Statecharts would provide a good way to know what transitions are allowed to occur. That would provide a logical place to do data preparation actions before they run.


@olivergeorge async APIs are probably similar to HTTP APIs like


No wait. I take it back. You said coeffects (not effects)


Are we talking about promises?

Oliver George06:05:09

Yes. In particular I was looking at react native AsyncStorage which returns promises

Oliver George06:05:35

Question is how to live with lazy data sources like that.

Oliver George06:05:04

A state machine approach works (do this, when it's done do that)

Oliver George06:05:11

but it's cluttering

Oliver George06:05:02

Would be nice if coeffect promises worked without extra code/events.

Oliver George06:05:43

As a separate point. It'd be nicer if it wasn't left till the last second to do since those little delays could affect the user experience.

Oliver George06:05:59

e.g. load the data early and it's ready when you need it


@mikethompson 3–4ms sounds suspiciously like on the next frame when running 60fps


Hmm. But there is a comment about that being wrong


I do know I appeared to be bitten by this when using core.async and asking for a timeout of 0 but getting instead 4ms.


(core.async uses a timer underneath)


Hi, I am using the re-com typeahead field and I have trouble when editing an existing value. This is my shortened code:

(let [file-to-edit (<sub [::fsub/file-to-edit])
        id (:id file-to-edit)]
        [ta/typeahead :data-source filter-file-type :class "ten-top-bot dummy-type-class" :attr {:id "type"}
         :on-change #(>evt [::fev/edit-file id :type %]) :model (:type file-to-edit)]
The problem is, a change in the typeahead field will update the type vaule of the file, as expected, but then the dropdown is not visible anymore. It does work if I dont set the :modelkey initially. But I loose to display the current type of the value then.


Is that considered a bug or am I missing something?


Do we have some guarantees on order of events-handlers, for example, when we use :dispatch-n? I have

{:dispatch-n (list [:put-a] [:read-a])}
where I put a into db, then want to read it


that’s not quite my usecase. And here’s - which means there is some ordering happening, but, alas, not quite my case too. So I think I’ll just go an empirical way


events are processed in the order they are dispatched.


dispatch-n dispatches events in the order provided


so :read-a would get the changes to :db?



😊 4
👍 4

[put-a] would be processed completely first then [:read-a] would be processed completely


ah, that’s great to know lol. I’d assumed that it was a series of async dispatches