This is a crazy good new feature!! I will love it. (Can you maybe put colors in pretty print?)

yeah, but more important things first 😛

Awesome feature. Thanks for your efforts @thheller! 🙂 We'll look at feasibility of direct integration of shadow-cljs in re-frame-10x at some point.

@superstructor although I'm working on this inside the shadow-cljs project for now all the underlying shadow.remote stuff is actually meant to be standalone at some point.

and re-frame-10x could act as a "runtime" itself too

but I'll get into more details on that in the future. just wanted to show an early preview 🙂

Anyone here has experience making shadow-cljs working together with dirac ? They seems not "compatible" with each other ...

Currently they are not compatible that is correct yes

Oh, just spotted https://clojurians.slack.com/archives/C0J01U7MY/p1571676963003500

I'll happily help anyone that is interested to work on this

but I don't have time to dig into this too much myself for now

I don't know what it needs but currently is makes direct use of the cljs.analyzer API I believe which means shadow-cljs can't intercept anything

@thheller I have very shallow knowledge about both, AFAIK 1) shadow-cljs has its own nrepl middleware (not using piggieback) to bootstrap a CLJS repl 2) and so does diract - it uses its own implementation Is that the major blocker?

yes

I think so at least. I don't really know what the dirac middleware does

@thheller IIUC 1. for a normal cljs repl, it's like clj repl -> piggleback mw (or whatever) -> websocket in browser/node. 2. For diract its clj repl -> dirac mw -> dirac agent -> websocket in chrome devtools -> program being debugged

The thing makes dirac shine is it can evaluate exprs even when a breakpoint is hit and the program suspended, because its eval goes through chrome devtools. While others like shadow-cljs/figwheel can't do that because their eval are based on "user-mode" websocket code which is a no-go when bp is hit Ofc there are other stuff from diract like pretty-printing cljs var names, but this is the biggest sell for me

in theory it should be possible to make this use the shadow-cljs API

but given that it doesn't use any of the default cljs.repl stuff that might be a lot of work

the stuff I'm currently working on may actually be relevant for this but it is a bit too early

what is it 🙂 ?

https://clojureverse.org/t/introducing-shadow-cljs-inspect/5012

the shadow.remote stuff would be relevant for dirac. right now it isn't capable of eval but it will hopefully be soon.

This looks awesome!!!! Going to try out this afternoon hopefully, think it will be a game changer for react native debugging

I haven't actually tested react-native yet since the test project I had for this doesn't work anymore for some reason

but it should work

[SOLVED] I'm trying to require static resources like this https://facebook.github.io/react-native/docs/images#static-image-resources Should I use js/require or import "as a library" in :require from ns? - Use (js/require "./../../resources/img.png")

@thheller works on react native a treat - got our whole re-frame db in there, it’s bloody brilliant!!

Is it possible to write a NodeJS server with Shadow-CLJS?

@neo2551 Yes, you want :target :node-script in your build

@thheller I would like to look into integrating dirac with shadow at some point, basically all I need is access to cljs compiler which is used by shadow-cljs - with figwheel I run dirac nrepl middleware in the same JVM as figwheel, so it can query figwheel’s state and use all “builds” and their relevant :compiler-env states

it is a bit fragile and hacky, because I touch internal figwheel’s state, but it works: https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/figwheel.clj

yeah I looked at that in the past but couldn't quite figure out how it all worked together

btw. that code is a bit more involved because I also let user call figwheel repl api through dirac repl command: https://github.com/binaryage/dirac/tree/master/examples/figwheel-main#you-can-control-figwheel-main-via-dirac

do you only need the compiler-env to read or do you actually modify it?

cljs compiler could modify it (and typically will)

e.g. when you def something

yeah thats the main issue. if you use the compiler directly shadow-cljs can't do anything

and shadow-cljs wraps the default compiler to make its additions

well, you have to do it yourself to get compiled js code to be sent to client

dirac must do the same thing, whatever it is

please note that I use compiler API at lower level, because compilation env could be affected by locals on stack, so I don’t only give it cljs code string, but also prepare env with locals on stack (when stopped on a breakpoint)

I need to do something like this: https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/eval.clj#L52-L62

hmm probably not the approach I would have taken

wouldn't it be easier to just eval (fn [the locals listed as args] (whatever-you-need-to-eval-using locals))

I wrote a simple health-checker using Serverless Framework and shadow-cljs. https://github.com/vharmain/serverless-healthcheck

so when you eval the generated JS you get a function

that you then call with the locals if you already have them?

no need to mess with the compiler state for that 😛

not sure if this would work well, at least it would mess with stack, in case of another breakpoint in that code, user would see that wrapper function

but :locals is supported cljs state config, why not use it? I have to mess with env anyways, for example to set current ns

that wrapper function could also interfere with return statements maybe, not sure if this would be a real issue

thrown exceptions would have it on stack, etc.

yeah, again I don't really know what you are doing

from that I'm seeing in that file you won't have much luck integrating shadow-cljs

as it pretty much replaces all of the cljs.repl API and doesn't support it

it does what piggieback does, but adds a bunch of tweaks

it is using repl api here: https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/eval.clj#L252

shadow-cljs doesn't support piggieback either and replaces that itself

nothing from cljs.repl is supported. some of it could be but most of it can't

here it is passing the compiler-env, which it got from figwheel (or created by dirac): https://github.com/binaryage/dirac/blob/master/src/nrepl/dirac/nrepl/eval.clj#L238

none of those things are supported 😛

but at some point you have to use cljs compiler and pass some compiler-env to it, no?

why not exposing it to me?

because it isn't "just" the CLJS compiler

shadow-cljs modifies it. the analyze as well as the "emit"

ok, let me ask differnt way, when you receive user input as string, you have to turn it into js code, and then send it back to client for js eval - turning it into js code could be some fn call [cljs-code-string env] -> js-code-string

why not exposing this api?

in your current impl env is probably always empty, but you can pass-through it for me down to cljs-compiler

I can provide that extremely easily yes

that is indeed how the entire REPL "compiler" code works

but it works a bit differently API wise ...

if you clone the shadow-cljs repo and run lein with-profiles +cljs repl

then (require '[shadow.cljs.repl-test :as x]) then (test-repl-anon-fn)

https://github.com/thheller/shadow-cljs/blob/master/src/repl/shadow/cljs/repl_test.clj#L143-L149

just for a "sample", this isn't an actual test

but this outputs the "repl state" which will include the generated JS

there is no actual "eval" anywhere the REPL code .. you can process a bajillion things without ever evaling anything

since that doesn't affect the generated code at all

but this API isn't exposed since no one asked for it before

all it does it generate instructions which the runtime will then execute

you mean runtime on the client side (js), right?

will be back in 10mins

yes

I could probably use this api, but I would need some additional support. Current ns could be “emulated” by emitting in-ns code, but :locals would be better than wrapping it with fn, also need support for source maps somehow

in dirac I inline source maps with generated js

you don't even need that

and maybe something else I’m not aware of right now, I wrote this code 3+ years ago, and I don’t have the context in my head

yeah me throwing random bits of information at you probably doesn't help

write an empty function that you need and I'll provide the implementation

like (defn please-generate-js-for-me [in-this-ns the-cljs-code-as-string])

maybe the extra locals as a map or so

nothing compiler-env related, I can set all that up myself if needed

what happens when cljs compiler throws? e.g. clojure macro throws?

you get the exception?

currently dirac is able to communicate it to client side with a stack trace

also dirac can capture all println stuff done in macros, etc

and send it to client side

then you capture *out*?

yes, but at lower level

at Java level

sorry I don't really want to get into this too deeply now

if you clearly define what you need I can set that up for you

talking directly to the cljs.compiler just isn't going to work since shadow-cljs can't do its stuff that way

ok, will think about it a bit…

but the same stuff is still possible, just accessed differently

What happens to calls to tap> in a production build?

right now they are left as is but don't do anything

you could potentially even strip them from completely using https://shadow-cljs.github.io/docs/UsersGuide.html#_code_stripping

:strip-type-prefixes #{"cljs.core.tap_GT_"}

haven't tried that yet 😛

but I'd like a tap> variant that is automatically removed in release builds

(tap> something) will just do nothing so thats totally fine without any overhead

(tap> {:some thing :foor "bar"}) or so would however still construct that map, and then throw it away which is overhead we don't need/want