Fork me on GitHub
#re-frame
<
2017-10-28
>
reefersleep12:10:29

get rid of your redundant render-func? 😄

qqq12:10:38

@reefersleep: can you directly render an atom ?

qqq12:10:49

if not, how does rc/render know to re-update when the atom changes ?

reefersleep12:10:55

I’m guessing not, but I’d test it for sure

reefersleep12:10:33

rc/render needs some kind of hiccup structure to display anything, I bet

reefersleep12:10:05

I don’t understand how your two questions are related

reefersleep12:10:33

Can you deliberate on your logic? 🙂

qqq12:10:19

I thought you were sugestnig (rc/render @gui-state app-div)

reefersleep12:10:20

If I wanted to display my state atom, I’d just wrap it in a [:div] or [:pre]

reefersleep12:10:59

Oh, sorry about that. I was kidding, actually. I see that you mean to refer to your let-binding in rc/render, but you managed to write two different symbol names 😉

reefersleep12:10:11

render-func and render-state

qqq12:10:33

I see, they should both be render-func .... that was a typo on my part (half refactoring)

reefersleep12:10:56

Maybe just: (rc/render [:pre @gui-state] app-div) ?

reefersleep12:10:21

not sure if you can use literal hiccup directly in rc/render

qqq12:10:29

why would that update when gui-state changes ?

reefersleep12:10:33

think I actually saw some issue related to it a while ago

reefersleep12:10:54

hm, good point

reefersleep12:10:13

Your code is pretty minimal already 🙂 Does it work without wrapping the dereffed state, though? I guess it’s indirectly wrapped in your app-div element

reefersleep12:10:53

Without wrapping it in some dom element, I mean.

qqq12:10:59

1. I'm no longer convinced my original question is working on anymore.

qqq12:10:11

2. the original problem was this: was streaming state from websocket from server to client

qqq12:10:20

so the client was literally "get this hiccup from websocket, render it"

qqq12:10:41

and this 'atom' was just a layer of indirection to store the state; either way, I'm okay with keeping the render-func around

reefersleep12:10:57

Yeah, that doesn’t seem superfluous to me

reefersleep12:10:05

you’ve even scoped it as minimally as possible

qqq12:10:20

yeah, I find the clj repl much nicer to work with than the cljs repl, so this way, I can write client side code in *.cljc, run the updates in clj/jvm, and have it send the hiccup to cljs, which just does a dumb render

reefersleep12:10:53

So it’s purely for development support?

qqq12:10:16

right, latency would be too much in production

qqq12:10:24

only works when browser + jvm are on same machine

reefersleep12:10:33

Alright. Nice tool!

reefersleep12:10:46

Maybe it makes sense to opensource it?

reefersleep12:10:57

If others agree with your proclivities

qqq12:10:26

don't want to deal with support + feature requests + .... for now 🙂

reefersleep12:10:59

Did you get it working again?

qqq12:10:08

yeah, all is working at the moment

reefersleep12:10:14

brilliant :thumbsup:

qqq22:10:16

I'm reading https://stackoverflow.com/questions/32367273/touch-left-touch-right-events-in-reagent -- and wondering -- is there sample reagent + touch event code somewhere ?

gklijs10:10:32

Not when I searched for it about a year ago, I ended up using hammer, https://clojars.org/cljsjs/hammer, and add it to a reagent component in the on-mount like:

gklijs10:10:13

(let [mc (new js/Hammer.Manager (r/dom-node this))] (js-invoke mc “add” (new js/Hammer.Pan #js{“direction” js/Hammer.DIRECTION_ALL “threshold” 0})) (js-invoke mc “on” “pan” #(let [direction (.-direction %)] (cond (= direction 😎 (dispatch [:change-direction [0 -1]]) (= direction 16) (dispatch [:change-direction [0 1]]) (= direction 4) (dispatch [:change-direction [1 0]]) (= direction 2) (dispatch [:change-direction [-1 0]]) ))) (reset! hammer-manager mc))