re-frame 2018-05-11 | Slack Archive

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.

mikethompson05:05:13

@olivergeorge async APIs are probably similar to HTTP APIs like https://github.com/Day8/re-frame-http-fx

Oliver George05:05:45

Yep.

mikethompson05:05:34

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

mikethompson05:05:38

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

Hukka06:05:52

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

mikethompson06:05:24

@tomi.hukkalainen_slac 60fps implies 16ms, I think? No it is more this ... http://www.chrisdanford.com/blog/2013/08/10/how-settimeouts-timer-clamping-works/

mikethompson06:05:19

Hmm. But there is a comment about that being wrong

mikethompson06:05:46

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.

mikethompson06:05:28

(core.async uses a timer underneath)

sveri08:05:07

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)]
    [:div   
        [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.

sveri08:05:22

Is that considered a bug or am I missing something?

troglotit10:05:19

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

manuel10:05:13

I think this explains it a bit: https://github.com/Day8/re-frame/blob/master/docs/Effects.md#order-of-effects

troglotit10:05:51

that’s not quite my usecase. And here’s https://github.com/Day8/re-frame/issues/465 - which means there is some ordering happening, but, alas, not quite my case too. So I think I’ll just go an empirical way

mikethompson10:05:23

events are processed in the order they are dispatched.

mikethompson10:05:13

dispatch-n dispatches events in the order provided

troglotit10:05:32

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

mikethompson10:05:48

yep

😊 4

👍 4

mikethompson10:05:26

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

eoliphant22:05:22

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

2018-05-11

Channels