Let VS Code extensions provide libraries to Joyride

[PEZ]

To make their extensions API:s more convenient for Joyride users, what if an extension could provide library namespaces to Joyride somehow. If we use Calva's current single API function as an example, we today need to do this to use it and have it print output and errors to the Joyride output channel:

(def calva (vscode/extensions.getExtension "betterthantomorrow.calva"))

(def calvaApi (-> calva
                  .-exports
                  .-v0
                  (js->clj :keywordize-keys true)))

(def oc (joyride.core/output-channel)) ;; Assuming Joyride is used

(def evaluate (fn [session-key code]
                ((:evaluateCode calvaApi)
                 session-key
                 code
                 #js {:stdout #(.append oc %)
                      :stderr #(.append oc (str "Error: " %))})))

Then we can use it:

(-> (p/let [evaluation (evaluate "clj" "(println :foo) (+ 2 40)")]
      (.appendLine oc (str "=> " (.-result evaluation))))
    (p/catch (fn [e]
               (.appendLine oc (str "Evaluation error: " e)))))

With a Calva joyride library provided that it could be cut down to something like:

(It could be argued that a (require '[calva.core :as calva]) would make this a bit more explicit and transparent.)

There are several ways this could be surfaced to the Joyride user. One is that Joyride looks in the folder of active extensions for a joyride directory and adds any such a libraries to its ”classpath”. If Calva had something like joyride/core.cljs in its extension folder, containing this:

(def ^:private calva (vscode/extensions.getExtension "betterthantomorrow.calva"))

(def ^:private calvaApi (-> calva
                         .-exports
                         .-v0
                         (js->clj :keywordize-keys true)))

(def ^:private output-channel (joyride.core/output-channel)) ;; Assuming Joyride is used

(def evaluate (fn [session-key code]
                ((:evaluateCode calvaApi)
                 session-key
                 code
                 #js {:stdout #(.append output-channel %)
                      :stderr #(.append output-channel (str "Error: " %))})))

The namespace betterthantomorrow.calva.core would be made available to joyride scripts. And the use could look simply like so:

(-> (p/let [evaluation (betterthantomorrow.calva.core.evaluate "clj" "(println :foo) (+ 2 40)")]
      (.appendLine (joyride.core/output-channel) (str "=> " (.-result evaluation))))
    (p/catch (fn [e]
               (.appendLine (joyride.core/output-channel) (str "Evaluation error: " e)))))

And joyride/paredit.cljs would be reached at betterthantomorrow.calva.paredit, and so on and so forth.

Since Joyride is available for these libraries, the code in them can parse EDN and whatever Clojure-y things that Joyride scripts themselves can do.

[borkdude]

I think it would make sense if extensions can export a "JS library" that can be required from joyride, like any other JS library in the Electron runtime.

(require '["betterthantomorrow.calva$v0" :as calva])
(calva/evaluateCode ...)

This reduces boilerplate but also makes it unambiguous from which extension the function is being used. The $ convention is standard CLJS and also used in nbb. Note that any sub-property of the extension can be selected, so if one would want to export a joyride specific part, one would write: (require '["betterthantomorrow.calva$v0.joyride" :as calva])

I think it makes sense to have these functions as compiled JS rather than code that should be interpreted, although both may have their use cases.

• Any extension can participate, not only those built with ClojureScript E.g. one could make a TypeScript extension and functions from those could be used from joyride as well in this way
• Avoid interpretation overhead (functions don't run through the interpreter first)

[PEZ]

Would this be merely a change in Joyride enabling this convenience require API to the regular exports of the extension?

[PEZ]

For the record: Nothing in the OP speculation of API limits it to ClojureScript extensions. It is more of a way to tuck commonly used Joyride scripts in a place where many users easily can reach them without copying them to their user scripts area.

[borkdude]

Would this be merely a change in Joyride enabling this convenience require API to the regular exports of the extension?

Yes (and/or any non-regular exports)

It is more of a way to tuck commonly used Joyride scripts in a place where many users easily can reach them

Yes I get that, but why should an extension export joyride scripts that still have to be interpreted, rather than offering functions directly to joyride?

[PEZ]

Yes I get that, but why should an extension export joyride scripts that still have to be interpreted, rather than offering functions directly to joyride?

It could be because they are Joyride scripts to begin with (made by the extension author or some user). Or because the functions need access to something in joyride (like with the example in the OP). Or because the functions want access to Clojure functionality (like parsing EDN). Or because writing it in ClojureScript is much more convenient than doing it TypeScript/JavaScript. (Better language, the REPL, no extension reloads, etcetera.) I can see lots of reasons. 😄

I don't think the two ways we've floated here are mutually exclusive, though. Making the regular API more convenient w/o Joyride wrappers is great. We should do it. Having a mechanism for providing Joyride libraries is also good.

[borkdude]

Agreed!

[PEZ]

For Joyride libraries like the OP suggests we could also do something similar to Calva's drams, and use a repository for it. Then it would be more convenient to crowd source common functions, wether they pertain to specific extensions or compositions of extensions, or no extensions.