Fork me on GitHub
#re-frame
<
2017-07-21
>
gklijs07:07:55

I might do something simular in an app, but using websocket instead. When on websocket where I always expect the server to send an awnser it would by very simple to put all objects that needs to be send in a channel, and block till I get a response or timeout.

lwhorton13:07:45

heya guys, has anyone found a way to wire response-values into the wonderful async-flow lib? https://github.com/Day8/re-frame-async-flow-fx

lwhorton13:07:51

i.e.

:rules [
{:when :seen :events :foo-loaded :dispatch [:do-bar response-from-foo]
]

mikethompson13:07:32

@lwhorton how do you mean response-values ?

mikethompson13:07:37

Not sure I follow

lwhorton13:07:30

sorry, what I mean is if event :foo-loaded is dispatched via dispatch [:foo-loaded args], it would be great if the :do-bar handler could expect (fn [db/cofx [args-from-foo]] ...)

lwhorton13:07:44

essentially i’m trying to use the async-flow to coordinate a multi-step client request … post /here, get response to post /there, then finally get response and post /done. this seems really well suited to a data-defined async flow, but at each step i need the xhr response to be handed forward to the next event declared in the rules :when :seen :here :dispatch [:there args-from-here], if that makes sense

mikethompson13:07:55

Ahh, right. It is assumed that state is held in app-db

mikethompson13:07:23

So the results from the former event is held in app-db, and there is available to the later event handler

lwhorton13:07:25

as a consequence of using async/flow it is stored inside db-path (defined in the config {:id … :db-path [:path :to :flow]})? or do you mean my handlers should store their results somewhere for downstream use?

danielneal13:07:59

@lwhorton I made a PR for this

danielneal13:07:09

( I think this is what you are looking for)

danielneal13:07:07

adds a :dispatch-fn to the async rules which you can use instead of :dispatch, which has access to the whole event vector

danielneal13:07:33

you can copy the whole file if you wanna try it out

mikethompson13:07:57

Sorry @danieleneal I haven't had a chance to review yet

danielneal13:07:03

hey no worries, probably needs some time to simmer anyway

danielneal13:07:38

thought I'd mention it because it sounds like @lwhorton has come across the same issue and might be able to try it out and see if it works

lwhorton13:07:09

i’m looking through it now. your docs do describe my exact problem (in addition to the additional ability to decalre a dynamic events-seen)

danielneal13:07:13

( 😄 the dynamic events-seen was in there already, just not documented that much so I added a few words in the docs about that)

lwhorton13:07:55

now that i think about it… i do like the idea of passing forward the args from events. however, one could probably make the exact same thing happen from the perspective of the handler using an interceptor that points to the state stored in the async-flow path, right?

lwhorton13:07:35

(reg-event-db 
  :my-handler 
  [(inject [:path :to :async-state :previous-event-id]] 
  (fn [db [args-from-previous-event]]
     ...
  )
)

lwhorton13:07:10

In that sense the handler would still remain transparent to where the data is coming from — you wouldn’t have to do some sort of lookup into the db’s async-flow state from inside the handler

lwhorton13:07:12

much like the docs/wiki describe injecting state such as from the localStore into your handler via an interceptor

danielneal13:07:32

mmm yes I think that could work too. I guess it depends really where you want to draw the boundaries between the handlers and the async flow.

lwhorton13:07:34

i would prefer your method, i think. even adding an interceptor onto a handler seems too tied together for my tastes… i would not, for example, be able to remove the async-flow and go back to a regular “‘chain of fx handlers” without also removing the interceptors from said handlers

danielneal14:07:01

cool, maybe if you have time try it out with a monkey patch - even if it doesn't work out for your case it would be useful feedback

lwhorton14:07:37

ill get to it shortly

eoliphant15:07:44

Hi all, I asked this previously, got sucked into some other work and promptly forgot the discussion I had here lol. When dealing with forms, it’s more typical to do a ‘local’ ratom then fire off events to update the app db, etc when the form is actually submitted,etc ?

pcj16:07:16

@eoliphant this is what I do. Although I usually store the 'current' data in the global db as well as the 'applied' data.

lwhorton17:07:27

@eoliphant it depends on the need of the UI, really. i would say my most likely case is a stateful ratom that uses some on-blur or on-submit to communicate the full state at some later point

jfntn17:07:34

Should it be possible to run tests using re-frame-test on node.js? Node is complaining it cannot find module’react’

eoliphant17:07:23

thanks @pcj and @lwhorton So @pcj your case though, what’s current vs applied, if you’re also using the local ratom?

pcj18:07:17

@eoliphant I do not use a local ratom. I just store the values in the app db. So when I change the values of form fields it updates the :current-form in app db. When I click apply it will move the values to the :applied-form

eoliphant18:07:02

ah ok so you don’t

eoliphant18:07:12

yeah i’ve been kind of playing around with both approaches

eoliphant18:07:46

my app has a fair number of forms, but i was doing kind of like you with a ‘current-form’ key

pcj18:07:11

it would seem that doing it that way is the re-frame approach. however like lwhorton said it depends on the UI. You could even just assign default values and on apply traverse the dom for the values

lwhorton18:07:44

there’s applied-state and current-state, is how I see it. you use a subscription that merges current-state over the top of applied-state for a form, when someone clicks “submit” then current-state becomes applied state, applied state goes nil.

lwhorton18:07:13

but again, that’s in the typical form where you dont “persist” anything until a user hits submit and confirms the changes

akiroz19:07:16

I usually just store all state in the app-db, having the view completely stateless makes it a bit easier to debug IMO

eoliphant22:07:40

thanks all, yeah I think I’m going to stick withthe app-db route for now