Fork me on GitHub
#re-frame
<
2017-09-05
>
genekim03:09:51

@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! :)

richard-nagelmaeker11:09:26

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)

danielneal11:09:08

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

richard-nagelmaeker11:09:38

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

richard-nagelmaeker11:09:51

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

richard-nagelmaeker11:09:31

here's the whole set of rules

richard-nagelmaeker11:09:45

{: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]}]}

richard-nagelmaeker11:09:14

in the console log I get the following responses:

richard-nagelmaeker11:09:35

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

richard-nagelmaeker11:09:18

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

danielneal11:09:33

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

danielneal11:09:58

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

danielneal11:09:21

one thing you are missing is a :halt? true

danielneal11:09:34

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

danielneal11:09:42

but the above looks ok otherwise

danielneal11:09:51

do you use re-frisk or anything?

danielneal11:09:04

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

richard-nagelmaeker11:09:12

Yes I had this before,

richard-nagelmaeker11:09:20

Same result though

richard-nagelmaeker11:09:20

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

danielneal11:09:44

what have you got at the moment for that handler?

richard-nagelmaeker11:09:15

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

danielneal11:09:38

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])

danielneal11:09:52

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

danielneal11:09:12

first have a read through this:

danielneal11:09:47

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

danielneal11:09:05

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

danielneal11:09:40

a sente-fx would look something like this

danielneal11:09:07

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

danielneal11:09:17

then you'd use it in handlers like this

danielneal11:09:06

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

danielneal11:09:29

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

richard-nagelmaeker11:09:47

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

danielneal11:09:27

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

richard-nagelmaeker11:09:11

OK, thanks for the advice πŸ˜‰

danielneal11:09:16

πŸ˜„ good luck!

len12:09:09

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 !

mccraigmccraig12:09:49

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

len12:09:46

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

mccraigmccraig12:09:16

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

mccraigmccraig12:09:34

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

len12:09:47

yeah though so as well - thanks will try that

lumpy12:09:43

@mccraigmccraig why not store images in app-db?

lumpy12:09:12

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

mccraigmccraig12:09:46

@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

lumpy12:09:58

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

mccraigmccraig12:09:09

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)

mccraigmccraig12:09:00

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

lumpy12:09:19

Good re-frisk PR

len12:09:48

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

mccraigmccraig12:09:21

how does it take it's auth @len ?

len12:09:50

Usually its in the auth header

len12:09:00

Its a JWT token

mccraigmccraig12:09:32

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

mccraigmccraig13:09:55

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

len13:09:11

That looks like the way we will have to go

mccraigmccraig13:09:37

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

vinai13:09:10

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?

mccraigmccraig13:09:54

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

reefersleep13:09:42

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.

danielneal15:09:37

that I was talking about the other day

andre18:09:02

tbh idk how it can be related with re-frisk

danielneal14:09:50

@andre I've tracked it down πŸ˜„ The issue I was seeing is because re-frisk-sidecar bundles an older version of tools.reader than the one I need, but because it is AOT compiled, I couldn't use :exclusions in the normal way. The only way I could fix it was by cloning the repo and removing the :main declaration from re-frisk-sidecar's project.clj.

andre14:09:21

@danieleneal fixed in 0.5.1 please check and let me know, thanks!

danielneal14:09:56

awesome! So quick πŸ˜„ Trying out now

danielneal14:09:30

Sweeeet! It works. Thanks for sorting that out

andre14:09:42

I knew that I forget to remove :main and I forgot. thanks for helping to find!

stvnmllr218:09:06

just tried the new version @andre Looks great.

danielneal19:09:29

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

danielneal19:09:21

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