[idea] Deeper integration with transit-js

[harold]

Hi! Thanks for squint, been having an absolute blast thinking about it and playing with it over the last couple weeks.

Is your feature request related to a problem? Please describe.
Experimenting with building a component of one of our systems in squint, interoperating over the network with existing clj/cljs systems, it occurred to me that transit-js (https://github.com/cognitect/transit-js) could be a nice bridging point - especially in the sense that it provides a "pure js" (https://github.com/cognitect/transit-js#transit-maps) notion of Clojure data.

I was pleasantly surprised when doing so essentially "just worked", but now I wonder about deepening the integration.

In one sense, this is sort of about destructuring (the exact example below), but in another sense it's about extending squint to be more fluent with a few more Clojure data types (esp. keywords, times (dates), uuids, sets (?)).

squint.edn:

{:paths ["src"]
 :extension "js"
 :output-dir "out"}

src/index.cljs:

(ns index
  (:require ["transit-js" :as t]))

(def transit-str "[[\"^ \",\"~:msg\",\"Squint\"],[\"^ \",\"^0\",\"is\"],[\"^ \",\"^0\",\"rad!\\n\"]]")
(def r (t/reader "json"))

;; Rad:
(println "Working:")
(def data [{:msg "Squint"} {:msg "is"} {:msg "rad!\n"}])
(println (->> data
              (reduce (fn [eax {:keys [msg]}]
                        (str eax msg " "))
                      "")))

;; Interesting:
(println "Also working:")
(println (->> (.read r transit-str)
              (reduce (fn [eax m]
                        (str eax (.get m (t/keyword "msg")) " "))
                      "")))

;; Someday?
(println "🤔:")
(println (->> (.read r transit-str)
              (reduce (fn [eax {:keys [msg]}]
                        (str eax msg " "))
                      "")))

(println "\nDone...")

Then...

$ bun install squint-cljs
$ bun install transit-js
$ bun squint watch

And in another terminal:

$ bun out/index.js 
Working:
Squint is rad!
 
Also working:
Squint is rad!
 
🤔:
   

Done...

Describe the solution you'd like
Not 100% sure what all this even implies, but perhaps it's thought provoking.

Describe alternatives you've considered
The component I'm building will, for now, need to be done in cljs instead of squint, which is fine. But I think this project is super-interesting, so I'm happy to contribute ideas.

[harold]

^ @charlesg3 - lower-case 'r' relevant to your interests.

[borkdude]

I think there should be a way to extend what get does from outside of squint. Then we can have a squint-transit adapter and it will work without having a direct dependency on transit.

[harold]

Wild idea - that sounds general. I like it.

[borkdude]

Note that there is also https://github.com/jorinvo/edn-data which implements EDN in pure JS. Won't solve your problem but nice to know it exists.

[harold]

Yup! Didn't know about that - thank you for the pointer. 👍

Could be interesting to benchmark this against everything else. Part of why I'm down this path is because transit-js/read is 3x faster than transit-cljs/read, which is itself 10x faster than clojure.edn/read-string (on node.js) for an important set of data for us.

And since this is lambdas, run time = 🤑 (:

[borkdude]

Have you considered using raw JSON (maybe with a hint of typing) or isn't that strong enough to express your data needs?

[harold]

I have - and I get that that is the squint-friendly way to do things (:, in this case I'm just bolting on to a larger existing clj/cljs system that operates on data with lots of namespaced keywords, and integers, and #uuid and #inst. Other different projects that are squint-only or are much closer to JS it's actually pretty clear how to handle data (which is neat, squint is awesome!). 😄

Transit is already a nice middle-ground, in real life a lot of the data is .nippy (https://github.com/taoensso/nippy), which we might end up eventually implementing at least a subset of the read-side of for JS. At this point we're just doing some early experiments to see if there are advantages to implementing at least parts of this system on other runtimes (Node right now).

[borkdude]

and I get that that is the squint-friendly way to do things

Well, the primary reason I mentioned it that it's probably the most optimized data format in JavaScript, but yes, it's limited

[harold]

Yup, for sure. Thanks again for all your time, effort, and consideration. It's all super-duper appreciated.