Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2017-07-06

Channels

#re-frame
<
2017-07-06
>
mikethompson00:07:03

@mattly @bradleesand These days the best way to write that view functions is: 

(defn item-rows 
  [row]
  (let [visible-cols  @(rf/subscribe [::visible-columns])]       ;; I put an @ on the front of the subscribe too
	  [:div.col-container] 
		;; ... contents inside of here
		))
Ie. no need to use Form-2

kennethkalmer14:07:11

I just pieced together a nice re-implementation of https://github.com/martinklepsch/s3-beam that suites my needs just fine, when I realized I hit a snag and I’m not quite sure how to get around it in a nice re-frame approach

kennethkalmer14:07:57

long story short, once the upload is done I need access to the storage key for the just uploaded file so I can send it along to the backend with the rest of the data

danielneal14:07:48

kennethkalmer: I'm also interested in a solution to this - when I use async-flow-fx, sometimes I need to use results from a previous event

danielneal14:07:19

at the moment I find a place in the db to put it

danielneal14:07:24

but that feels kinda messy

kennethkalmer14:07:19

I’m not willing to do that! I started typing that out and thought I’d rather take a timeout and think this through properly

kennethkalmer14:07:53

the uploader component does the entire dance in isolation, and I patiently wait thanks to re-frame-async-flow-fx before submitting

kennethkalmer14:07:07

just that storage key…

kennethkalmer14:07:56

so s3-beam uses core.async under the hood, and now it makes a lot of sense to me… I guess ideally/naively I’d like to fire off the upload process in an event handler and wait for it to complete before carrying on… I get that with async-flow-fx, except that everything is silo’ed off from each other. Now I’m considering using core.async too to wait for the storage-key (or an error) before carrying on. This replaces the async-flow, but feels a completely different to the rest of the app and I’d like to avoid that

kennethkalmer14:07:41

alternative is to dispatch the upload process with everything needed to complete the final api call later by having the chain dispatching continuously until complete, this also feels messy

danielneal14:07:51

kennethkalmer: haha yes definitely we've hit the same limitation as I think I've tried this approach too

danielneal14:07:05

have you any inkling what might work?

kennethkalmer14:07:08

so far only dispatching everything, maybe using an effect handler can make it look better

danielneal14:07:54

how do you dispatch everything - where do you get the storage key from? Or do you mean not using async-flow-fx and just using a series of dispatches

kennethkalmer14:07:09

yeah, drop async-flow-fx in this case

danielneal14:07:24

mm yeah I've switched back and forth between this and async flow

danielneal14:07:07

defining everything at the top/co-ordination level sure feels better and helps keep the individual handlers small and ignorant/decoupled

danielneal14:07:29

I wonder if async-flow could be extended a bit so you could bind or collect information from the individual handlers

kennethkalmer14:07:28

Me too, I’m already leaning on the just released 0.0.8 for the events predicate function functionality…

danielneal14:07:08

kennethkalmer: ooh I didn't know about this new thing

kennethkalmer14:07:00

for each file/attachment I create a unique identifier with gensym and that gets dispatched along every step of the way and used in the app-db to track upload progress, etc… so my async-flow’s need to match the correct identifier in case of multiple uploads running concurrently

kennethkalmer14:07:17

I don’t have concurrent uploads yet, but that is kinda the very next step

danielneal14:07:27

Something that looks a bit like this, perhaps 

{:when :seen :events [:upload/success storage-key]
                           :dispatch [:backend/set-storage-key storage-key] :halt? true}

kennethkalmer14:07:15

I don’t have storage-key at this stage of the match

danielneal14:07:34

mm that was fanciful anyway, wondering what something would look like if you wanted to locally bind bits of the result

kennethkalmer14:07:54

{:first-dispatch [:upload/start identifier file]
   :rules
   [{:when     :seen?
     :events   [(fn [[e i _]]
                  (= [e i] [:upload/done identifier]))]
     :dispatch [::create-folder params]}

    {:when   :seen?
     :events [::folder-created]
     :halt?  true}

    {:when   :seen-any-of?
     :events [[:upload/failed identifier] ::request-failed]
     :halt?  true}]}

kennethkalmer14:07:29

:upload/done gets dispatched with the storage key, that was my first naive attempt

kennethkalmer14:07:59

hence the predicate check in the events, the _ is the storage key but doesn’t matter when the flow is defined

danielneal15:07:27

wishful thinking - if "custom-dispatch" existed? 

{:first-dispatch [:upload/start identifier file]
 :rules
 [{:custom-dispatch  (fn [[event identifier & args]]
                       (when (= [e i] [:upload/done identifier])
                         (let [[storage-key] args]
                           [::folder-created storage-key])))}

  {:when   :seen?
   :events [::folder-created]
   :halt?  true}

  {:when   :seen-any-of?
   :events [[:upload/failed identifier] ::request-failed]
   :halt?  true}]}

kennethkalmer08:07:20

Or :dispatch could just accept an fn, just like events could be a fn that acts as a predicate

danielneal10:07:50

@kennethkalmer I've made a fork of re-frame-flow-fx that does this

danielneal10:07:37

it provides an extra dispatch rule, :dispatch-fn which takes the seen event and returns a seq of events to dispatch

danielneal14:07:55

I wonder if @danielcompton has any thoughts on this situation

kennethkalmer14:07:41

Hmm, I’m gonna sketch out what it could look like with a :upload-file effect to smooth over any verboseness in the handler

mattly16:07:36

@mikethompson yeah I'm still on 0.8, I haven't budgeted time to upgrade to 0.9.x yet

danielcompton21:07:33

@kennethkalmer would be happy to take a PR on s3-beam to see your re-frame approach to this, we've got something internally we use for re-frame

danielcompton21:07:48

but we haven't converted it to use effects

kennethkalmer21:07:26

@danielcompton, maybe I'll start with a gist of the component and how it I use it to kick off some ideas

kennethkalmer21:07:49

Will do that in the morning, knackered atm