@andre exciting! Congrats! Checking it out right now -- can you send me a link to any description of active subscriptions? Would love to take it for a spin! :)

https://github.com/Day8/re-frame/blob/master/docs/SubscriptionFlow.md

Question, is async-flow-fx the prefered way to send an asynchronus message to the back-end? (I'm using sente for sending the message)

you can write your own custom fx to suit your need, but model it off e.g. reframe-http-fx

I'm unable to tell async-flow-fx the sending of the message was successful, to trigger the next rule.

oh

go on

So this is in the rules defenition: >quote :events [:datamos/success-send-message]

here's the whole set of rules

{:id :datamos/send-msg-flow :db-path [:datamos/msg-flow-state] :first-dispatch [:datamos/send-message] :rules [{:when :seen? :events [:datamos/success-send-message] :dispatch [:datamos/success-message]} {:when :seen? :events [:datamos/fail-send-message] :dispatch [:datamos/failed-message]}]}

in the console log I get the following responses:

re-frame: overwriting :event handler for: :datamos/send-msg-flow

re-frame: overwriting existing post event call back with id: :datamos/send-msg-flow

don't worry about those error messages too much, they're an artifact of figwheel usually

ok, I understand

but you're not seeing [:datamos/success-message] being fired?

true

one thing you are missing is a :halt? true

you can end up with multiple flow handlers if that is not there in your end state

but the above looks ok otherwise

do you use re-frisk or anything?

I'd recommend it for seeing what's going on

Yes I had this before,

Same result though

What should the [:datamos/send-message] fn return?

what have you got at the moment for that handler?

To be clear, handler = :datamos/send-message?

if you were using re-frame-http-fx it would be something like

(reg-event-fx :datamos/send-message
        (fn [cofx [_ message]]
           {:http-xhrio {:method :get, :uri "..." ... :on-success [:datamos/success-send-message] :on-failure [:datamos/fail-send-message])

but if you're using sente, you'd need to implement a different fx handler for the sente call, you can't use http-xhrio

ah ok

first have a read through this:

https://github.com/Day8/re-frame/wiki/Effectful-Event-Handlers

I think the best thing to do would be to create a websocket/sente fx

you don't necessarily even need async-flow-fx at this stage, that's more for co-ordinating lots of things

a sente-fx would look something like this

(reg-fx :sente 
   (fn [args] 
     (let [{:keys [on-response timeout message]} args] 
      (chsk-send! message timeout (fn [resp] (reframe/dispatch (conj on-response resp)))

then you'd use it in handlers like this

OK, I see.

(reg-event-fx 
   :datamos/send-message
    (fn [cofx _]
       {:sente {:message [:datamos/rdf-message db]
                :timeout 5000
                :on-response [:datamos/reponse-received]}

the above will have typos etc in but that's the rough kinda shape of it

thank you very much, I 'll let you know the result

try and get something like this working first before moving on to async-flow-fx

OK, thanks for the advice 😉

😄 good luck!

Hi folks, quick Q - I have a remote http service that generates graphs - png files - how would I load those into the views ? any pointers where to start would be welcome !

@len render an [:img {:src ""}] element

If that img is dynamic would I just store the image in the db then render it ?

i would not store images in the app-db @len

i would put a url for the image into the app-db

@danieleneal Yep! it worked. Thanks.

yeah though so as well - thanks will try that

@mccraigmccraig why not store images in app-db?

Do large values slow it down in someway? Double memory storage?

@lumpy a couple of reasons - it will make inspecting your app-db painful, and probably crash a cljs repl if you try from there - putting opaque values into app-db makes it harder to interpret - in one way images are plain data and not opaque in the way that functions or types are, but they certainly aren't easy to interpret

So more from a debugging stand point? img-abtteurndn3747.png isn't very easy to interpret either.

yes (and while img-abtteurndn3747.png isn't easy to fully interpret, it is easy to visually compare with another url and observe if it has changed)

True

although if you have some tool which can give you visual display of blobs in your app-db images may be easy to intrepret

Good re-frisk PR

so the url that gets the image needs auth, how to do that ?

how does it take it's auth @len ?

Usually its in the auth header

Its a JWT token

sounds like you will have to download the image with an ajax request then, and display either from a blob or from local filesystem

another alternative - if you have control of the server you could get the server to take the JWT token as a url param as well as a header

That looks like the way we will have to go

our api uses JWT auth and takes either/or a header or request param - it works quite nicely

Is there a re-frame variation of form-3 react components, or is it common to just use regular calls to reagent.core/create-class?

just reagent.core/create-class afaik @vinai , certainly that way in my codebase

thanks @mccraigmccraig 👍

I support that notion; from my perspective, the form-3 component IS create-class, and therefore a part of the reagent API, not the re-frame API.

that I was talking about the other day

tbh idk how it can be related with re-frisk

just tried the new version @andre Looks great.

Yeah I think it's a dependency. The old version of refrisk works fine but when I upgrade I get that. I just haven't sussed out what is bringing in an older tools reader

It will only affect code using the clojure 1.9 syntax for namespaced map keys which is probably why no one else gets it