Fork me on GitHub
#mount
<
2016-01-22
>
jrychter10:01:51

@tolitius: I converted all my server-side code to mount and it works well. I'm quite happy with the results!

jrychter10:01:13

But I also have a question. I would like to modify the state from elsewhere (other functions, not just lifecycle functions). Is that… legal? simple_smile

jrychter10:01:47

An example is: start defines a pub/sub structure, and later on I start subscribing channels to it. I need to keep track of subscribed channels so that on stop I can unsubscribe them properly.

jrychter10:01:26

Or should I just keep those in a separate atom?

dm311:01:59

you can have a ns to track the subscriptions, e.g. subscriptions/subscribe!

jrychter11:01:40

Then again, perhaps I don't have to do this at all… core.async docs aren't that clear on this, but if you close the source of the pub, pub should close as well, which should also close all subscribed channels.

jrychter11:01:16

I guess I could also keep that additional state in an atom inside the defstate state

jrychter12:01:06

Well, for ClojureScript the picture isn't so rosy. In one of my namespaces, modifying the file causes the start function to be called twice. Not good.

jrychter12:01:38

Also, the order seems wrong: ns1 :require's ns2, but ns1's start is called first, then ns2's start. Twice. I think I'll stick to manual state management here for now…

jrychter12:01:09

Could mount be somehow confused because it is only required in two namespaces?

jrychter12:01:06

What's worse, this problem seems to appear and disappear without any regularity that I can notice.

dm312:01:03

does this happen during the development?

jrychter12:01:32

Yes, with figwheel. But I checked all combinations of cleaning/rebuilding.

jrychter12:01:01

It seems to have goten rare (or nonexisting) once I converted the entire app to mount, but I'm still looking carefully.

jrychter13:01:47

Ok, so the problem definitely exists. I have a dispatcher namespace, that is required by pretty much everything else. Changing that file results in start being called twice, also after browser reload. I have to clean JavaScript and restart the whole figwheel environment for things to work again. What's curious, it is only this namespace that seems to be so affected.

tolitius15:01:14

@jrychter: dispatcher is on cljs side, right?

tolitius15:01:55

also if you are not using it, can you try 0.1.9-SNAPSHOT

tolitius15:01:53

I find lein cljsbuild to behave oddly at times (environmental), hence I am using boot for most of the projects, it always starts clean. I know it would be a lot to change, but I definitely recommend giving it a try.

tolitius15:01:54

> "the order seems wrong: ns1 :require's ns2, but ns1's start is called first, then ns2's start" mount simply obeys the compiler. it could theoretically happen when moving states from one place to another.. without reloading

jrychter15:01:45

So, in order: everything I described in on cljs side. Clojure side works great. I am not using 0.1.9-SNAPSHOT, will try right away.

jrychter15:01:43

As for boot, been there, done that — we tried boot in a project in our company, it has its own set of problems. Nothing is perfect.

jrychter15:01:37

What is curious is that after changing and saving dispatcher.cljs, stop gets called (once) and start gets called (once). So everything looks good. But if I reload the app, start will get called twice. It will get called twice from then on, until I clean the JavaScript files.

jrychter15:01:13

Trying 0.1.9-SNAPSHOT now.

jrychter15:01:08

I get the same thing with 0.1.9-SNAPSHOT. I guess I must not change the dispatcher file, then. I will implement a one-shot atom checking if start was run twice.

tolitius15:01:52

I wonder whether mount detects that something with a state was reloaded before it was stopped and restarts it, and then you call (mount/start) in the app which result in two start calls. do you see messages about ns recompile in the console:

jrychter15:01:53

Yes. And everything works as expected, except for the dispatcher namespace. Triggering recompilation for that one does everything as expected (it stops and then starts everything that depends on it). But after a reload the start method gets called twice. Every time I start the app.

jrychter15:01:37

My current fix is to rm -rf resources/public/static/js after this happens. This triggers a full recompilation next time I change something, and fixes the double-start problem.

tolitius16:01:27

But after a reload: you mean after figwheel pushes changes to the browser you see :start being called twice?

tolitius16:01:08

i.e. or when you reload the page in the browser..

jrychter16:01:45

After figwheel pushes changes to the browser things are fine. But after a browser reload (Command-R in my case) start gets called twice.

tolitius16:01:58

need to think more about it... would you mind to create an issue? when I have time I'd like to check whether it is caused be environment or this is truly a defect

jrychter16:01:59

Of course. I am still trying to narrow it down.

tolitius16:01:39

great, thanks!

jrychter16:01:10

What I find worrying is something I noticed right now:

jrychter16:01:13

The little number (2) on the left. I added a logging message at the toplevel of my dispatcher namespace, and it also gets a (2). Why would things happen twice? Checked this both with figwheel and with a production cljsbuild with :advanced optimization. Same result.

tolitius16:01:14

> with a production cljsbuild with :advanced optimization first time you open a page everything loads normally, but after you reload the page :start gets called twice?

jrychter21:01:15

No, the last message was only about duplicated log message that I added in my namespace. I expected the namespace to be loaded just once, and to see one log message. Instead, I see two. mount doesn't seem to produce any logging when compiled with :advanced.