(ns server.main
  (:require
   [ui.hiccup :refer [hcc-server]]
   [ui.html :as ui-html]
   ["express" :as express]
   ["serve-static" :as serve-static]
   ["node:http" :as http]
   ["react" :as react :refer [createElement]]
   ["react-dom/server" :as rdc :refer [renderToPipeableStream]]))

(defonce server (atom nil))

(def serve (serve-static "build", #js {:index false}))


(defn request-handler [^js req ^js res next]
  (let [did-error (atom false)
        stream (atom nil)]

    (if (not (= (.-url req) "/"))
     (serve req res next)
     (reset!
      stream
      (renderToPipeableStream
       (clj->js (hcc-server ui.html/index))
       #js {:onError (fn [e]
                       (reset! did-error true)
                       (js/console.error "Error rendering" e))
            :onAllReady
            (fn []
              (js/console.log "ALL READY"))
            :onShellError
            (fn [err]
              (set! (.-statusCode res) 500)
              (.send res (str "ERROR:" err)))
            :onShellReady
            (fn []
              (set! (.-statusCode res) (if @did-error 500 200))
              (.setHeader res "Content-Type" "text/html")
              (.pipe ^js @stream res)
              (.end res))})))))

(defn start [bs]
  ^:dev/after-load
  (let [app (express)]
    (.use app request-handler)
    (reset! server (http/createServer app))
    (.listen ^js/Node.http.Server @server 8000 (fn [] (println "Server running on port 8000")))
    bs))

server code that I run with node

hcc-server is the macro

I have ui.hiccup cljs

(ns ui.hiccup
  (:require-macros [ui.hiccup] [hicada.compiler :refer [compile]]))

(ns ui.hiccup
  (:require 
    [ui.html]
    [hicada.compiler :refer [compile]]))

(defmacro hcc-server [body]
  (hicada.compiler/compile 
    (eval body)
    {:create-element 'react/createElement 
     ;:transform-fn (comp)
     :array-children? false}))

(defmacro hcc-client [body]
  (hicada.compiler/compile 
    body
    {:create-element 'js/React.createElement
     ;:transform-fn (comp)
     :array-children? false}))

notice the eval body that I needed there in hcc-server, without that, it was not working. Now I am trying the client side and it's breaking with eval, which makes sense, but can't get it to work with anything

well, what is it doing in the first place. (clj->js (hcc-server ui.html/index)) this makes no sense to me

why clj->js?

because otherwise react complains that can't really do anything with the returned clojurescript object

so what is this macro supposed to return

body is the ui.html/index SYMBOL when the macro is called

react createElement calls, last code snippet has the macros in full

that should be evaled so that instead of the symbol it's a hiccup edn

ok, but eval evals the code in clojure. I assume this is CLJS code?

what is ui.html/index?

hiccup edn

literally just some vectors with keywords and strings

(def index [:div "x"]) or something like that

but it's large, I can't always type it and maybe I want to use different hiccup edns in multiple projects, so I need a way to require and use them both on the server and on the client to render react nodes

ok, so I assume that your intent is to compile that form. this isn't possible in CLJS.

I am not sure I follow

what is getting called at macro expansion time is (hcc-server ui.html/index)

it works on node

but you want to know the runtime value of ui.html/index, which doesn't work

the server returns the correct html generated from hiccup

no, nothing like that

it's edn. it's literals, totally static.

then move the compile call

the macro should read it in clojure and create the react call

turn that into (def index (html [:div "x"])), so the macro is getting the actual EDN, not a symbol referring to it

again, I want to be able to reuse it, so keeping it in edn form is important

what does reuse mean?

and again, I already made it work in nodejs

so I know it's possible, very confused why you say it's not

I do not know what the hicada compiler is doing, but did you verify that the code you think you get you actually get?

might just be something that behaves the same, but isn't actually the same

yes, I opened up the javascript file

so with the eval?

yes

ok, then I assume the ui.html file is cljc?

yes

i wish it could be .edn

ok, then clojure can actually find the code, but the CLJ variant

yes, but the macro just needs to know the edn, nothing else, doesn't call cljs or js anything

then I don't understand what you are trying to do in the first place. everything seems to behave as you want then?

not really, when I do the same eval code for the client, it breaks 🙂

well, ... this is exactly why I warn against using .cljc code. I assume that is the part you don't correctly understand.

well, i would say it's highly likely i don't understand any of this correctly 🙂

.cljc is two files in one. a CLJS file and a CLJ file. clj eval can ONLY find the CLJ parts, it has no knowledge of CLJS parts

that part I understand

make your life easier and don't use .cljc files at all if you can avoid it

I tried to use your custom reader thing, but it just didn't work at all

can you explain what you are trying to do in the first place?

sorry for not being more specific here, I couldn't get the reader conditionals to activate, that's why I have two macros

don't know why custom reader would factor into anything here, so that statement just confuse me 😛

why are you using .cljc files?

😄 how far should I go back

is your intent in any way to run this in CLJ? or is this purely CLJS running the browser and/or node?

I need to write this macro because of hicada. And doing hiccup needs macro anyway, since I don't want js to evaluate static stuff over and over again

why do you say you'd prefer .edn files?

so that's where the clj comes in

what is it your are trying to do?

why do you want hicada?

because edn is just data, it doesn't matter what runtime. clj cljc cljs and who knows how many others are all context dependent and behave very differently under different builds and runtimes

when it is truly just data then make it a .edn file, nothing stopping you from doing that

i don't want hicada, but manually writing this thing for react is a huge task, and hicada seemed the freshest of all the options for hiccup and clojurescript

but I have my doubt that they are truly just data?

hicada looks like an unmaintained dead library to me? why do you say "freshest"?

it was really difficult to load then the edn files into the client build. node server was very easy of course.

you can use the edn file via macros, they don't need to be loaded at runtime. but I'm still guessing at which problem you are trying to solve exactly

you want to optimize over using just hiccup if I understand correctly?

it seemed the one with recent activity, others were either older or didn't use hiccup or did it with runtime transformation

but I may be wrong about this, not saying I spent more than 1-2 days googling hiccup libraries and reading their docs

yes, I do want to optimize the hiccup parsing to compile time, at least where it's feasible, like with SSR. So everything that can be render on the server, shouldn't then be re-parsed on the client side

thats not what is going to happen? the server spits out html, it doesn't spit out hiccup?

I need to try this edn into macro thing again.

or whatever renderToPipeableStream spits out, I don't actually know.

it spits out html, yes

edn file or not doens't matter to the compilation part one bit

it was a week ago when I was trying to do this, so I don't have all the details. need change the code again.

If I understand you correctly, I should use some clojure/java thing to read the file, then the edn reader to parse it, and then somehow I can give it to the macro, hopefully. 😄

I’m compiling cljs code with shadow, and I’ve configured it with this:

{:output-dir "./cljs-server"
                   :target :esm
                   :runtime :node
                   :js-options {:js-provider :import}
                   :modules {:app.server {:exports {add app.server/add}}}
                   :release {:compiler-options {:optimizations :advanced}}}

Is it possible to connect to a running repl after importing the CLJS modules into a node program?

https://github.com/thheller/shadow-cljs/issues/979

it does not currently

Is it possible to use the devtools for the node or npm_module for this? Or does it need to have its own devtools?

I would like to try implementing this, can you recommend a good place to start?

ok, in the build config you may set :runtime :custom :devtools {:client-ns your.attempt}

your.attempt is a namespace. you can probably start with a copy of one of the defaults

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/client/browser.cljs

don't start with this one, as it is the most complicated since it also handles the HUD and CSS reloading stuff

which you don't need it node

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/client/node.cljs

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/client/npm_module.cljs

feel free to ask questions about them, they all work the same just adapted to specific platforms

they'll connect to the websocket, and then handle the reloading parts

the common bits are extracted out already, the main differences are in the eval parts

so :npm-module evals the code entirely differently https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/client/npm_module.cljs#L96-L114

than the others, because of the specifics of commonjs

mainly the require exports etc "specials"

for esm things are already in the global scope somewhat

so you could probably take the browser, rip out everything related to HUD and CSS and change it to use the ws package instead of js/WebSocket

at least that is likely how I would start. I have not yet done any work related to this

could maybe also start with the npm-module client, but rip out all the commonjs bits

Would it be worth to use a js/WebSocket polyfill based on ws ?

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/client/npm_module.cljs#L186

https://github.com/thheller/shadow-cljs/blob/master/src/main/shadow/cljs/devtools/client/browser.cljs#L322

thats all it takes to swap out the impl, yes you could probably polyfill that in different ways

if you remove all DOM/CSS related bits from the browser ns it'll likely just work

yup yup that’s what i was feeling it could be

node always makes me want to throw me pc out the window. so I haven't looked at it in a while 😛

esm on node is even more niche

why not just use a different target for node? why does it have to be esm?

or is it again because of the JS parts that need to interact with the CLJS code?

yup yup you got it

im trying to run the CLJS code in runtimes like node, like Deno or Bun.sh

esm is a nice format to design for all of these different tools

https://github.com/thheller/shadow-cljs/issues/923

deno is also open 😉

esm is ok, the platform specific parts are the problem

ie. node wants ws package, browser wants js/WebSocket, don't even know what deno or bun want

maybe it all works somehow if they all have a js/WebSocket available 😛

they’ll probably try to use the node option but deno may try to implement js/WebSocket

these runtimes are trying to converge on the web apis even for the server stuff

so they could work haha, which would be great!

that'd be great indeed

having everything be platform specific was never great to begin with

how should i attempt to test my changes? do still use the shadow-cljs sources in my own source paths? or do I need to build the cli and link that to node_modules?

like I said. you put your.attempt ns in your project in your source path

there is no need to either fork or work on shadow-cljs directly

don't even need the shadow-cljs sources at all. changes to the CLJ parts should not be required in any way

its just a regular CLJS namespace, nothing special about it

I thought I would importing shadow-cljs devtools modules if I was copying the node or browser implementation. Can I still re-use some code with my implementation?

I don't understand that question. there are no "shadow-cljs devtools modules". they are just regular CLJS namespaces, that you compile with your build

you can access any of the existing namespaces just fine yes

I see, so a namespace like this would be available to my code: shadow.cljs.devtools.client.env?

yes

ah sorry, that’s new to me

okay i understand now what you’re saying

its all just CLJS namespaces, you can even replace existing ones by just putting them on your source path with the correct name

did you get the setup working? any progress?

Yup yup I got it setup, just need to tinker on it

Okay happy to report that copying the browser version and replacing roughly two lines works so far

Probably just need to shake out the unrelated browser stuff and it should be fine I think

good to know

Should we try to replace the HUD calls with a server hud?

I never look at the hud anyways, so I wouldn't

Okay sounds good, I’ll continue to tweak this until I think it’s ready for a review, then I’ll try to setup a PR