FAQ for avoiding "two window" race conditions

[olivergeorge]

I have two browsers open pointing at my single-page webapp (for a sane reason, I promise[1]). The figwheel repl broadcasts meaning I'm unsure which is responding which is confusing. My work around is calling figwheel.client.socket.close_BANG_() in the documentation browser console to close the socket.

The figwheel documentation doesn't seem to advise on how best to manage these situations.

I think a FAQ entry might be helpful.

[1] I have a page in my app which provides documentation based on the code (describes re-frame subs, handlers including args and docstrings). It builds when the app runs and has some search/filter behaviour.

[bhauman]

So this is tricky right?

The best way is to have two builds even if they are duplicate. Each one will have a different build-id and thus repl messages will be routed based on which build you start a repl for.

You can start and stop builds within the figwheel repl. You can also switch the repl to a different build by typing :cljs/quit and then choosing the other build.

[bhauman]

If you would like to give this a try and create a FAQ entry I would much appreciate it.

[olivergeorge]

Thanks Bruce.

That approach could be quite inconvenient depending on how the server side is setup. It would require two server side templates, different urls and other config. I wonder if a pure "figwheel" solution would be a good alternative... perhaps there are two right answers.

The point of confusion is the "first responder wins" aspect of sending repl commands. A mode which guarantees which browser will respond would be perfect. A policy of "last loaded wins" would provide a simple reliable mechanism to reason about.