Fork me on GitHub
#hoplon
<
2016-01-28
>
alandipert13:01:54

@puzzler: the anonymous cell is not GC'd because it references (and is referenced by) history. but yes you can use destroy-cell! to disconnect a cell from every other so that it can be GC'd

dm315:01:55

hey, was wondering how you approach live reloading while keeping state with hoplon apps. I've found a sample of (boot-reload) using on-jsload to refresh the whole page, but that's too aggressive as all of the state gets discarded

dm315:01:56

was thinking it would be enough to trigger the (html ...) snippet reload on-jsload, but can't find a good way to do that

alandipert15:01:36

@dm3: defonce is one way, another way is to keep state you want to persist in a "storage atom"

dm315:01:03

ok, what method do you use to reload the application?

dm315:01:17

I was using the

(defn refresh []
  (set! (.-href (.-location js/window))
        (.-href (.-location js/window))))
hack, but this throws away defonces

dm315:01:44

also feels a bit sluggish

alandipert15:01:56

boot-cljs-reload?

alandipert15:01:08

then the page reloads when source changes

dm315:01:40

well, if I have an index.hl page and something that it depends on, upon changing the dependency ns the sources get sent to the browser but the page isn't re-rendered

dm315:01:49

maybe I'm not understanding something here

dm315:01:41

but it seems that I need to trigger my top level (html...) form on reload

dm315:01:19

yep, seems to be working

dm315:01:20

put (html... ) into (defn render []) and calling

(defn refresh []
  (. js/hoplon.app_pages._index_DOT_html render)
in (boot-reload :on-jsload 'app/refresh)

alandipert15:01:03

interesting, i haven't needed to do that yet

dm315:01:43

strange. Maybe I'm managing my state differently than you do? I have a (defelem sheet ..) in a separate ns and several instances of it in the index.cljs.hl. Index ns also holds the state for all of the sheets, which it passes down to the sheet elems

levitanong18:01:28

Hmm. I’m experiencing weird stuff with *session*. Say boot is running, and I’ve done something to place a value in *session* (like logging in). When I refresh the page, that value i placed in *session* disappears. However, when I restart boot, that value is there. Refreshing again makes it as if *session* has no value. Does anyone have an idea of what’s happening?

flyboarder18:01:45

@levitanong: I add a check when the page loads which populates cells if session already has values such as a user token

levitanong18:01:02

@flyboarder: Even if I do a js/setInterval, polling the server for the session every 200ms, the session appears to contain no values, even if it should. Maybe I’m doing something wrong. 😛

levitanong18:01:21

@flyboarder: I’ve also added an add-watch to monitor the *session* cell whenever it changes, but it triggers only when i start up boot. 😦 When I log in and log out, the add-watch doesn’t trigger. So I’m at a loss. o_O

flyboarder18:01:49

hmm, so session is always empty? are you sure you are setting a value 😛

laforge4918:01:47

Are you running the hoplon chat demo @levitanong ?

levitanong18:01:42

@flyboarder: Session has a value when i load boot. So it’s like, it works as expected only upon a fresh boot dev. 😆

levitanong18:01:32

@laforge49: admittedly, I’m not. I’m trying to adapt the principles in the chat demo onto my app. I’ll be cloning that repo just to make sure though.

flyboarder18:01:50

@levitanong: how are you setting the new session values?

flyboarder18:01:17

can you println and see if it is set on the server when you expect it?

levitanong18:01:20

(swap! *session* assoc :user value)

laforge4919:01:21

Session is coming from the client's cookie.

laforge4919:01:57

And is saved there when updated by the server side.

levitanong19:01:22

@flyboarder: Yeah, the swap is working it seems. When I sign in, session is populated.

levitanong19:01:52

@laforge49: So theoretically it should take some time before session is updated on the server, yeah? And that would mean that if I have a js/setInterval, sooner or later it should work. But it doesn’t 😞

laforge4919:01:54

not. You add values on the server side and those values are subsequently represented to the server with each request.

laforge4919:01:05

so there is no delay.

laforge4919:01:45

the only way the values can disappear is if you update session yourself. Perhaps by executing the login code at an inappropriate time.

laforge4919:01:12

Perhaps you can put a println in the server code at every point where you update session?

laforge4919:01:54

--basically the same thing flyboarder said earlier. simple_smile

levitanong19:01:56

@laforge49: @flyboarder: Welp, Just tried running the chat demo, and it’s working as expected, so it’s gotta be my code.

laforge4919:01:35

That's one of the main purposes of the demos.

laforge4919:01:08

I often have problems finding a bug until I am convinced that it is in my own code.

flyboarder19:01:20

@levitanong: So the session is updated when you login, we confirmed that

flyboarder19:01:50

are you trying to get these values in your app client-side?

laforge4919:01:39

great question flyboarder!

flyboarder19:01:05

i think the issue is confusion around the session cell, it is a server cell, so the value is not client side

laforge4919:01:28

Though you can likely read the cookie, hmm?

levitanong19:01:35

Well, what I meant is, client-side, on load, I run a get-state rpc

levitanong19:01:51

which should return the session data

levitanong19:01:05

as in the castra-chat demo

flyboarder19:01:11

right and that should set a local client side cell with a value

laforge4919:01:36

but not the contents of session.

levitanong19:01:16

hmm @laforge49 I’m not sure I follow...

flyboarder19:01:42

@levitanong: @laforge49: I have to run but i think laforge49 can help you sort this now simple_smile

laforge4919:01:56

You update session with a session id on login. And then later use the session id to get the app session-specific data.

levitanong19:01:05

Thanks for your time, @flyboarder! Have a great day simple_smile

flyboarder19:01:14

you too, ill be around later

levitanong19:01:30

@laforge49: I thought session id was a specifically castra-notify thing 😮

laforge4919:01:26

but the concept of a session id is pretty common. this is because the session needs to be kept small since it is passed constantly back and forth between the client and server.

laforge4919:01:00

Given a session id, then the app server side can identify the larger dataset that is specific to the client.

laforge4919:01:12

Note that the lifecycle of the contents of session and the app's session data are different. The app's data disapears when the server goes down, but the data in session does not.

levitanong19:01:32

Okay, I’m beginning to see… so the problem I’m facing is happening because every time I refresh the page, the server is using a new session ID because i’m not keeping track of it?

laforge4919:01:35

--unless you are writing to disk. simple_smile

laforge4919:01:55

that's a little off

laforge4919:01:19

the old session id is represented. But your login can overwrite it with a new id.

laforge4919:01:53

I address these issues in the castra notify chat demo.

laforge4919:01:08

--they get a bit involved though. 😞

levitanong19:01:28

ah, hmmm… I’m basing my app off the castra chat demo though, not the castra notify chat demo.

laforge4919:01:35

I try to preserve the login and session id as much as possible there.

levitanong19:01:43

in that case, would the session id still be a possible cause for my problem?

laforge4919:01:26

if you understand how things work and what your code is doing, then everything gets simple. Getting there is not always simple. simple_smile

levitanong19:01:08

that is true 😛

laforge4919:01:23

so play with castra chat demo. put in print statements on both client and server side. And develop a good understanding of what's happening. THEN review your code.

levitanong19:01:46

Okay, got it simple_smile

laforge4919:01:02

Ping me any time!

levitanong19:01:06

thanks, @laforge49! I really appreciate you taking the time to help me simple_smile

laforge4919:01:07

Well, pass it forward, hmm? I'm a newbie myself and get LOTS of help. What goes around, comes around. And clojure is a GREAT community. simple_smile