Dealing with multiple CLJS runtimes

[thheller]

Not sure if this is better suited for cider, cider-nrepl or here.

A "Runtime" in CLJS is a JS engine that has loaded the compiled CLJS code and somehow connected to a REPL server like figwheel or shadow-cljs. There are several situations where it is likely that a given CLJS build has multiple connected runtimes. Say you are building a Browser-targeted SPA and have it open simultaneously in Firefox and Chrome. A react-native app running in multiple devices/emulators and so on. Each of these runtimes can potentially be used to eval code for a REPL. For CLJ there is only one given Runtime (the JVM) so it doesn't have this issue.

@bhauman recently did some work on figwheel that added the ability to "focus" a given "session" referring to what I call "Runtime" I think) but given that this in figwheel.repl it is not a generic API and therefore would put additional burden on Tool authors to support various different implementations.

I wonder if it would make sense if we added a couple different nREPL ops so that clients can query which runtimes/sessions are available and present a "smarter" UI to pick which to eval in.

It would also be possible to send a nREPL message notifying the nREPL client (eg. cider) that a Runtime disconnected or connected, eg. when the user closed the browser or reloaded the page. All client-side REPL state will be lost and the cider may want to do something?

cider already asks which build to connect to by reading the config for shadow-cljs but it would be more accurate to pick the runtime to connect to.

Any thoughts?

[thheller]

Since names are important. Here are the terms I currently use. Suggestions welcome.

Runtime

As explained above. Basically anything that can eval JS code and is connected to a "Server" via some kind of mechanism (eg. WebSocket) so that we can actually send code there and receive results.

Session

A Client connected to the Runtime via some Server. Similar to nREPL session but more limited since CLJS supports bindings differently and they don't really translate well in an async environment. The Session could maintain the current namespace but all other bindings can't really be guaranteed.

There can be many sessions per runtime. A Client might have many sessions.

Server

figwheel, shadow-cljs, etc. Anything that a Runtime or a Client can connect to and also has a running nREPL enpoint.

Client

Anything able to connect to a Server and starting a Session, e.g. cider, Cursive, etc.

[bhauman]

I agree with the intent of this suggestion, but think that it may apply to a different middleware?

As piggieback's api, which wraps the cljs.repl/repl api, allows only one IJavaScriptEnv, and it is the IJavaScriptEnv which is responsible for evaluating Javascript in an environment. It just so happens that the figwheel IJavaScriptEnv multiplexes connections but this behavior isn't supported by all IJavaScript envs.

Since the current piggieback API is intended to work with any single IJavaScriptEnv, this seems like you are speaking about either an addition to the IJavaScriptEnv protocols that allows for focussing sessions/connections. Or perhaps allowing the launching of a cljs.repl with several IJavaScript environments that one can choose between.

It should be kept in mind that one can currently create more nREPL sessions and launch a new piggieback on each session with the IJavaScriptEnv of their choice. This behavior could be surfaced better in cider, it could allow for the creation of several CLJS REPLs and allow one to focus an editor buffer on a single repl.