clojurescript 2023-11-24

JB21:11:49

Hi. I have probably a dumb question about clojurescript and piggieback. (I've mostly been using clojure JVM but making a foray into cljs, deps.edn and using http://practical.li's spacemacs config) I've been trying to set my deps.edn to a nice config to allow figwheel-main run a dev build with cider repl autocompleting even some of the js funcs/objects (hence spacemacs/doom). I've got a simple reagent app working and I'm poking at (js/document.getElementById "app"). I can see the resulting webpage using the .-innerHTML property, so I do know that everything is connected (as well as hotload working). My question is, when I look at js DOM objects at the web console, I get functions and attributes of object as a simple expansion caret. When trying to inspect the object in cider (with :dev/reload-cljs added to -A), the (js/document.getElementById "app") returns #<cider.piggieback.UnknownTaggedLiteral@59a5c7d2> If running the :nrepl command from the piggieback github (`clojure -R:nrepl -m nrepl.cmdline --middleware "[cider.piggieback/wrap-cljs-repl]"`) and then connecting to it with cider, I lose my autocomplete but only get the string representation of the object, #object[HTMLDivElement [object HTMLDivElement]] Is there a best practice for the setup of deps.edn to use with figwheel-main that gives all the bells and whistles to http://practicl.li's spacemace/doommode emacs's cider, or is this simply a case where I should keep a web console open to explore what keys are available in the DOM? My messy deps.edn currently looks like this (with some of the dependecies of packages I'm looking to explore).

{:deps {org.clojure/clojurescript {:mvn/version "1.11.54"}
        com.bhauman/rebel-readline-cljs {:mvn/version "0.1.4"}
        com.bhauman/figwheel-main {:mvn/version "0.2.18"}
       ;; hiccups/hiccups {:mvn/version "2.0.0-RC2"}

        reagent/reagent {:mvn/version "1.2.0"}
        cljsjs/react {:mvn/version "18.2.0-1"}
        cljsjs/react-dom {:mvn/version "18.2.0-1"}
        cljsjs/d3 {:mvn/version "7.6.1-0"}
        cljsjs/codemirror {:mvn/version "5.44.0-1"}
        cljsjs/material-ui {:mvn/version "5.14.7-0"}
        cljsjs/vega {:mvn/version "5.25.0-0"}}

 :paths ["src" "target" "resources"]

 :aliases

 {:build-dev
  {:main-opts ["-m" "figwheel.main" "-b" "dev" "-r"]}
  :fig {:main-opts ["-m" "figwheel.main" "-b" "dev" "-r"]}
  :nrepl
  {:extra-deps
   {nrepl/nrepl {:mvn/version "0.8.3"}
    cider/piggieback {:mvn/version "0.5.3"}}}
  :dev/reloaded-cljs
  {:extra-paths ["dev" "test"]
   :extra-deps  {djblue/portal             {:mvn/version "0.49.0"}   ; portal data inspector
                 org.clojure/clojurescript {:mvn/version "1.10.844"}
                 lambdaisland/kaocha-cljs  {:mvn/version "1.5.154"}
                 org.clojure/test.check    {:mvn/version "1.1.1"}}}}}

(Before anyone asks, I'm looking at only figwheel because I'd like to avoid the mess of npm and having to learning how to move yet another package management system to possible airgapped networks. I know that will most likely require cljsjs and foreign lib externals if I want to keep compiled sizes down).

vemv22:11:05

cider.piggieback.UnknownTaggedLiteral sounds worth a GH issue - we at cider always aim to provide an optimally usable experience :) I would primarily recommend shadow-cljs over figwheel. Both have official support in CIDER, have have gotten some love this year (just like https://github.com/clojure-emacs/clj-suitable has - another important component) Thanks to suitable's eval-based completions, you can inspect the DOM and stuff by simply using your autocompletion framework (like company-mode for Emacs)

vemv22:11:08

Another approach to DOM inspection might be to feed a dom object into https://github.com/djblue/portal (CIDER inspector lacks cljs support at the moment; it's on the radar)

JB10:12:23

#Also sent to the channel

Thanks for the reply. Checked out portal and it returned the same as the cider repl. Guess I've just been feeling spoiled with all the clojure tooling (stuff like spectre). Looked like aim at the child nodes of the DOM would get some returns, but eventually it was just reading the body. Didn't find the same issue with any js objects though so this might only be because I was aiming at the dom. (or because of figwheel instead of shadow-cljs). Either way, thank you for the reply.

vemv12:12:58

No issue. You might have luck implementing datafy/nav for DOM stuff!

JB10:12:23

replied to a thread:Hi. I have probably a dumb question about clojurescript and piggieback. (I've mostly been using clojure JVM but making a foray into cljs, deps.edn and using http://practical.li's spacemacs config) I've been trying to set my deps.edn to a nice config to allow figwheel-main run a dev build with cider repl autocompleting even some of the js funcs/objects (hence spacemacs/doom). I've got a simple reagent app working and I'm poking at `(js/document.getElementById "app")`. I can see the resulting webpage using the `.-innerHTML` property, so I do know that everything is connected (as well as hotload working). My question is, when I look at js DOM objects at the web console, I get functions and attributes of object as a simple expansion caret. When trying to inspect the object in cider (with :dev/reload-cljs added to -A), the `(js/document.getElementById "app")` returns `#<cider.piggieback.UnknownTaggedLiteral@59a5c7d2>` If running the :nrepl command from the piggieback github (`clojure -R:nrepl -m nrepl.cmdline --middleware "[cider.piggieback/wrap-cljs-repl]"`) and then connecting to it with cider, I lose my autocomplete but only get the string representation of the object, `#object[HTMLDivElement [object HTMLDivElement]]` Is there a best practice for the setup of deps.edn to use with figwheel-main that gives all the bells and whistles to http://practicl.li's spacemace/doommode emacs's cider, or is this simply a case where I should keep a web console open to explore what keys are available in the DOM? My messy deps.edn currently looks like this (with some of the dependecies of packages I'm looking to explore). {:deps {org.clojure/clojurescript {:mvn/version "1.11.54"} com.bhauman/rebel-readline-cljs {:mvn/version "0.1.4"} com.bhauman/figwheel-main {:mvn/version "0.2.18"} ;; hiccups/hiccups {:mvn/version "2.0.0-RC2"} reagent/reagent {:mvn/version "1.2.0"} cljsjs/react {:mvn/version "18.2.0-1"} cljsjs/react-dom {:mvn/version "18.2.0-1"} cljsjs/d3 {:mvn/version "7.6.1-0"} cljsjs/codemirror {:mvn/version "5.44.0-1"} cljsjs/material-ui {:mvn/version "5.14.7-0"} cljsjs/vega {:mvn/version "5.25.0-0"}} :paths ["src" "target" "resources"] :aliases {:build-dev {:main-opts ["-m" "figwheel.main" "-b" "dev" "-r"]} :fig {:main-opts ["-m" "figwheel.main" "-b" "dev" "-r"]} :nrepl {:extra-deps {nrepl/nrepl {:mvn/version "0.8.3"} cider/piggieback {:mvn/version "0.5.3"}}} :dev/reloaded-cljs {:extra-paths ["dev" "test"] :extra-deps {djblue/portal {:mvn/version "0.49.0"} ; portal data inspector org.clojure/clojurescript {:mvn/version "1.10.844"} lambdaisland/kaocha-cljs {:mvn/version "1.5.154"} org.clojure/test.check {:mvn/version "1.1.1"}}}}} (Before anyone asks, I'm looking at only figwheel because I'd like to avoid the mess of npm and having to learning how to move yet another package management system to possible airgapped networks. I know that will most likely require cljsjs and foreign lib externals if I want to keep compiled sizes down).

2023-11-24

Channels