Figwheel light ideas

ideas.md

It would be interesting if Figwheel could essentially decorate any implementation of IJavaScriptEnv, taking on the responsibility of watching the filesystem (perhaps even delegating that to ClojureScript :watch, and expanded :watch-fn, and perhaps minimally calling IJavaScriptEnv -load when Figwheel determines it is needed.

Then, for those REPLs that can participate, if IFigwheelSupport can be extended to them, they can do further cool stuff. (Perhaps IFigwheelSupport is actually necessary while IJavaScriptEnv as described in the previous paragraph is insufficient, and a more fancy impl of -load is needed?)

That way, things like the existing Node REPL could be minimally supported by Figwheel, as well as Ambly, the Browser REPL, etc.

What does IFigwheelSupport do?

Perhaps somewhere there is a HUD interface and Figwheel can ask a REPL to display things on its HUD? An iOS or Android-specific REPL could delegate to Objective-C or Java that implement a HUD using platform-specific UI widgets.

Perhaps another thing is the "punch-through" where you add capabilities to talk to the underlying Clojure to do things.

In general though, that's all that is floating around in my mind right now: A way for Figwheel to decorate any REPL with minimal features, based on IJavaScriptEnv, and then additional interfaces that allow them to opt into more extensive features. (Or for other people to independently extends those REPLs with those featueres, given the flexibility of Clojure).

Really agreeing that this should have minimum impact for the compiler until this crazy way of doing things has more time in the world.

I have been thinking that the idea of a single ICompileWatcher (on-compile, on-warning, on-error) fits into to the idea of a watching compiler. It would be great if this could present warning and error information, its a bonus to have any sort of file change data.

The rest of the changes can be detected from the environment given this information. Maybe grabbing this info from the env can eventually reside in the notion of the CLJS build API.

It's kind of a bummer that the client of this ICompileWatcher api would have to asynchronously collect the warnings to associate them with a compile.

It seems with these ingredients we could decorate a REPL-Env to autoloading in a straightforward way.

As far as the bigger picture is concerned, I am thinking that along with IDEs, build scripts that can compose all this crazy stuff folks want to do with build tools are probably going to be a winning strategy. It would be nice if the API didn't "get in the way" of this happening, but rather supported and encouraged it.

Ahh, OK, so today you can :watch "src", and optionally supply a zero-argument fn to :watch-fn. Perhaps the change is to allow passing a :compile-watcher which is an implementation of ICompileWatcher.

One immediate benefit outside of Figwheel light would be that, say IDEs could also provide an ICompileWatcher impl and decorate lines in their code editors that have warnings and somesuch.

Even if you don't :watch "src", but supply a :compile-watcher, then if you go into a REPL and type (require 'foo.bar :reload) and there is, say a syntax error in that namespace, today, it prints that stuff right in your REPL. If you are in Cursive's REPL, it could do more, like highlight the problematic lines. :)

An additional thought: Would ICompileWatcher matter to Clojure? Perhaps it does for ClojureScript because it must be transpiled? But in Clojure does it only matter when AOT?

This sounds good.

This doesn't deliver the info to the REPL-Env. A smarter ReplEnv may want it. But that may just be a complected REPL.

What do you think?

Time is a good thing. ICompileWatcher seems like it would work really well.

I would add one more method to ICompileWatcher:
before-compile
after-compile
on-warning
on-error

before-compile would allow one to mark certain files for recompile before the compile kicks off
before-compile should be passed the files that changed