Fork me on GitHub
#shadow-cljs
<
2021-02-21
>
Adrian Smith00:02:55

I have a shadow-cljs project using a node-script build, I'm using shadow-cljs node-repl then connecting and trying evaluate my file that has npm imports like ["robotjs" as robo] when I try and evaluate the file I'm getting clojure.core.spec complaining about that, where am I going wrong?

Adrian Smith00:02:45

ah looks like I had to do (shadow/node-repl) whilst inside the repl

thheller09:02:59

indeed, REPLs first always start out in CLJ when you connect over nREPL

Adam Kalisz11:02:38

@theller I don't know, if this came up earlier. For some time, I was unable to load the development version of our ClojureScript project on localhost in Chromium. It worked in Firefox, but was rather slow. I didn't know at all, what caused it. So I tried to gather some data about it. I cleared the cache of Chromium (deleted ~/.cache/chromium) and this helped a few times but the problem always returned. I have resorted to deleting of the build directory of shadow-cljs. The result was that the development version of our project loaded immediately in Chromium and Firefox as well. I don't have any further data, just wanted to let you know.

Remy13:02:49

Hello, I’m trying to setup custom response headers in order to do a cross-origin request during development. I’ve been reading [the user guide](https://shadow-cljs.github.io/docs/UsersGuide.html) and [a stackoverflow question](https://stackoverflow.com/questions/65907176/how-to-properly-setup-shadow-cljs-for-hot-reload) but it seems the headers only apply to the shadow-cljs “dashboard” server (eg. 9630), not the app itself. I tried the following so far: - wrapping shadow.http.push-state/handle and calling the wrapper in :dev-http. Same result when overriding :push-state/headers - setting :devtools :http-handler, again pointing at my wrapper I just wanted to ask here before going through the source, maybe there’s something i misunderstood entirely from the docs. I’m starting the server up through emacs cljs-jack-in with

npx shadow-cljs -d nrepl/nrepl:0.8.3 -d cider/piggieback:0.5.2 -d cider/cider-nrepl:0.25.9 server
;; dev/custom_handler.clj
(ns custom-handler
  (:require [shadow.http.push-state :refer [handle]]))


(defn handle-wrapper
  [req]
  (handle (assoc-in req
                    [:http-config :push-state/headers]
                    {"conten-type" "text/html; charset=utf-8"
                     "access-control-allow-origin" "*"})))
;; shadow-cljs.edn
;; shadow-cljs 2.11.7
;; clojurescript 1.10.773
{:deps {:aliases [:dev :shadow :cljc]}
 :nrepl {:port 8777
         :middleware [refactor-nrepl.middleware/wrap-refactor]}

 :dev-http {8281 {
                  :root "resources/public"
                  :push-state/headers {"access-control-allow-origin" "*"}
                  }
            }
 :builds {:app {:target :browser
                :output-dir "resources/public/js/compiled"
                :asset-path "/js/compiled"
                :modules {:app {:init-fn remyrd.rock-n-call-frontend.core/init}}
                :devtools {:http-root "resources/public"
                           :http-port 8280
                           :http-handler custom-handler/handle-wrapper
                           :preloads [devtools.preload]
                           }}}}

thheller13:02:45

basically as soon as you want to do something like this you should be using your own http server instead

thheller13:02:22

what is serving your HTML that makes this necessary in the first place?

thheller13:02:05

the handler isn't supposed to modify the request coming in. instead it should modify the response

thheller13:02:10

(defn handle-wrapper
  [req]
  (-> req
      (handle)
      (update :headers merge
        {"access-control-allow-origin" "*"})))

thheller13:02:37

also why do you have a dev-http and then another in devtools?

Remy13:02:02

Just to showcase the two possibilities i tried

Remy13:02:33

Right, silly me it should’ve gone in the response. I agree I should be using my own http server, for now i’m just doodling and I needed this data from an external api.

thheller13:02:52

maybe you want to proxy instead?

Remy13:02:04

probably… i see there’s a section about it that i can read :)

Remy13:02:49

Well i’m trying to figure out what is the best way to serve cross-origin content on a static webpage, probably I’m forcing this approach but I wanted to avoid spinning up a server

thheller13:02:38

sounds like you are maybe trying to solve this in the wrong way? the API server handling the requests is the server that needs to set those CORS headers

thheller13:02:50

not the shadow-cljs server serving the .js files

Remy13:02:27

oh i see, yes the origin in allow origin makes more sense now, thanks

Remy13:02:00

Btw, thanks for the quick answers and the tool