Open olivergeorge opened 8 years ago
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.
If you would like to give this a try and create a FAQ entry I would much appreciate it.
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.
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.