This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-08
Channels
- # bangalore-clj (4)
- # beginners (160)
- # calva (132)
- # cider (18)
- # clara (1)
- # cljsrn (2)
- # clojure (129)
- # clojure-boston (1)
- # clojure-europe (5)
- # clojure-italy (5)
- # clojure-losangeles (1)
- # clojure-nl (33)
- # clojure-uk (49)
- # clojurescript (88)
- # cursive (20)
- # datomic (5)
- # duct (3)
- # fulcro (33)
- # graphql (7)
- # jobs (3)
- # kaocha (3)
- # nrepl (41)
- # off-topic (58)
- # pathom (18)
- # re-frame (1)
- # reagent (5)
- # shadow-cljs (148)
- # spacemacs (7)
- # tools-deps (7)
I’m considering trying to connect to nREPL from a web app / chrome extension for a project. is there any prior art for something like this?
I’m a bit bummed that it requires a separate dep. the dream would be that I could just connect to any old nREPL server
yeah. I wish there was some way for Chrome to connect to a regular ol’ socket 😭 pulling in an HTTP server for every project using nREPL seems potentially problematic
> I’m a bit bummed that it requires a separate dep. the dream would be that I could just connect to any old nREPL server (edited)
That’s hard to do as you need to bundle somehow an HTTP server with the REPL. Leiningen used to ship Drawbridge at some point, but I’m not sure if that’s still the case.
In theory we could have a trivial self-contained http implementation bundled with nREPL, but there never was a lot of demand for this.
would you take a PR with something like that? I might be able to put something together, but I also understand if it’s just increasing surface area to support for something not many other people need
what's the usecase here, @lilactown?
I previously implemented my own shoddy protocol on top of websockets for Node.js / JVM, but I was thinking i might be able to simplify my life by just connecting directly to a REPL
specifically I’m now pivoting to a chrome extension that would connect to a remote session: CLJS in an inspected page, Node.js, and JVM. I previously implemented different “adapters” for each platform, but I know that most projects already have nREPL which would reduce dependencies users would have to install and potentially reduce the differences in implementation
I looked at that as well. it’s still another transport, right? and it didn’t look like it had been updated in awhile, so I wasn’t sure if it supported the latest nREPL
I've seen some roll-your-own HTTP implementations, and if you are super narrow about the usecase, it can be manageable. But all depends on what it looks like
yeah. I’m afraid that it will bloom into “now nREPL has a fully-fledged HTTP server impl” lol
> I looked at that as well. it’s still another transport, right? and it didn’t look like it had been updated in awhile, so I wasn’t sure if it supported the latest nREPL
> yeah. I’m afraid that it will bloom into “now nREPL has a fully-fledged HTTP server impl” lol
@dominicm You won’t need to sideload it, thouhg. You could inject it in the initial payload you’d use to convert a socket repl to nREPL. Once we get there that is. @cgrand already has some branch where the injection works, so I guess that’d be just an extension of this idea.
yeah, I know. Just remember that demo you showed me way back in December and that we spoke that the injection could be a good way to provide custom transports seamlessly.
Good point. That approach would work for conventional clients, but not for @lilactown’s use case.
I kind of want just a dumb endpoint that I could dump some code into to “inject” stuff, like a heavier HTTP transport if needed