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: