Razzle is a SSR library like Next or Remix, but without the whole framework attached. The js-provider option did fix the hooks thing. Thanks!

Another question though: does shadow-cljs watch inject code into the output? And is there a way to change this behavior? I get all kinds of issues with the framework trying to run what seems to be stuff watch is doing in the browser on node lol, like saying WebSocket() is undefined

Everything is fine with shadow-cljs compile

yes, it injects the :runtime specific (default :browser) tools

you can set :devtools {:enabled false} or set :runtime :custom to stop that (in the build config)

Ah, nice; that worked. Thanks again!

> is there a macro to create a go-block and a channel in one operation? Hard to understand what you mean. What would the macro expand to? Also, just in case - go itself creates a channel within it that it returns to the caller. > also whats the convention for channels that should just block until all operations are done and not pass any information Just return something that's not nil. Maybe true - up to you. Or close! that channel - that's what go does when its body results in nil.

sorry was away for dinner - aha! so how do i put stuff on the channel that go creates?

That would be the result of the go's contents - you don't put anything there explicitly.

okay so if i just put true on the last line or even a <! or <p! that will be put on the channel?

Yep.

wonderful!

while i'm at it I have another question about core async

i have a function that is called by a framework

the framework expect my function to return a promise

the framework is firebase cloud functions

to accomplish this i do this (def go-idkollen-se-callback (functions/https (fn [req res] (js/Promise. (fn [_resolve _reject] (go (try

now i can do the actual thing i want to do beneath the try

when im done i call resolve or if i catch an error i forward it to reject

basically, i wonder if i can convert the channel that is created by the go block into a promise

Pretty sure your current solution is the way to go, assuming you even need core.async.

i do a lot of async operations in my cloud function

thats why im converting my code from nestled promises

Also, yes, I realize this is probably not the right way to solve this. (while the correct solution is also welcome, I'm specifically asking about the technique of monkeypatching javascript code before the user submitted code executes -- because by then it will be too late)

https://clojurescript.org/reference/compiler-options#preloads

(turns out the real answer was just a version conflict)

I'm looking at your example now. The confusion probably is that for in clojure is not an imperative loop like .forEach in JS

for generates a lazy seq of results. if you want to cause side effects, you can use doseq

but with promises this is a bit more complicated. hmm

doseq assumes that you're doing things synchronously

but so does .forEach

anyway, changing for to doseq should match your JS closer

Ok, I will start down the doseq path first! I wasn't sure if I needed to use another utility from promesa.

you could maybe use chain + map to create functions that are executed serially, but this isn't what the JS example is doing either

Oh interesting, I wil look at that.

doseq works though. It looks like that was all I needed to change.

Is this the best approach to deal with async code like this or is there a more idiomatic Clojure way?

(apply p/chain (map (fn [i] #(p/do (println "Waiting" i "seconds") (p/delay (* i 1000)))) (range 5)))

well, as I said, in JS you didn't serialize the promise operations either

there might be synchronous API library available as well for mysql

Hmm, I would just use async/await, but it doesn't look like that is easily available in ClojureScript.

True. It is available in #cherry (experimental CLJS compiler) and #clavascript (experimental CLJS syntax to JS compiler)

In nbb and normal CLJs you just chain promises, like I did above

Got it. I'll try that too and also check out the compilers you mentioned. Appreciate it!

This would probably also work:

(p/all (map (fn [table] (.execute conn ...)) table-names)

❯ clj -A:cljs -M -m cljs.main -re node -r
ClojureScript 1.10.773
cljs.user=> (js/Error. "my specific error")
#object[Error Error: my specific error]
cljs.user=> (pr-str (js/Error. "my specific error"))
"#object[Error Error: my specific error]"
cljs.user=> (read-string (pr-str (js/Error. "my specific error")))
WARNING: Use of undeclared Var cljs.user/read-string at line 1 <cljs repl>
Execution error (TypeError) at (<cljs repl>:1).
Cannot read properties of undefined (reading 'call')

cljs.user=> (require 'cljs.reader)
nil
cljs.user=> (cljs.reader/read-string (pr-str (js/Error. "my specific error")))
Execution error (ExceptionInfo) at (<cljs repl>:1).
Invalid symbol: Error:.

Yes, but it's what errors seem to serialize to by default, sorry I should have declared the import

the error is a javascript native object. I don’t think it serializes at all. That’s just a string representation of it

how would you do this in pure js? ie, make an error, and then eval it to get back an error object

I get you but a lot of the time in cljs you can just write fairly arbitrary stuff to edn and pull it back out with then defaulttagreader, it seems weird to me that a "primitive" would cause an error, but I just wanted to check that I'm not doing anything mad and this is just what happens

I guess I need to find the hook for pr-str for error, and modify that then at least these datatructures will lossy roundtrip without error

You could hack on the printer or you could walk your datastructure and replace them with clojure data

I’d transform data before I would attempt to work on the printer/reader

I see what you mean

Thanks

it does say that they are serializable. I don’t see how to render to a string and back. But if you can figure that out you can walk and turn them into some special data structure that includes the serialized form. And then on the other side can rehydrate them with a walk that undoes the serializing side

>

data: {
>       label: (
>         <div>
>           Welcome to <strong>React Flow!</strong>
>         </div>
>       ),
>     },

I would try this:

{:id       "2"
 :data     {:label (reagent/as-element [:div "Default Node"])}
 :position {:x 100 :y 125}}

Does that survive the cljs->js conversion?

I think so

That worked! Thanks!

Documented function forms are

(element tag-or-text)
(element tag & children)

(element "div")
Interprets as text instead of tag.
Returns a text node containing string "div".

(element :div)
Throws:
Execution error (Error) at (<cljs repl>:1).
No protocol method DOMBuilder.-element defined for type cljs.core/Keyword: :div

I'm even more confused after trying to make sense of the source. https://github.com/clojure/clojurescript/blob/r1.11.60/src/main/cljs/clojure/browser/dom.cljs#L13-L15

(extend-protocol DOMBuilder

  string
  (-element
    ([this]
       (log "string (-element " this ")")
       (cond (keyword? this) (gdom/createElement  (name this))
             :else           (gdom/createTextNode (name this))))

...

defn element
  ([tag-or-text]
     (log "(element " tag-or-text ")")
     (-element tag-or-text))

...

you probably want to look for other ways to work with the DOM. I doubt anyone uses clojure.browser.dom and its not exactly "maintained"

It's a built in package. Shouldn't it at least do what it claims to on the cover?

if you ask me these namespaces should have been removed a decade ago. but they are staying for historic reasons just in case someone might be using them. if you ask me nowadays its better to look elsewhere.

the test for keyword is there for historic reasons as well. very long time ago keywords were just represented as a string and didn't have their own type

the code was never adjusted accordingly I guess

Gotcha

A deprecation notice sure would be nice, if they're just going to abandon something, but still ship the eroding code.

I am not too up on the latest in javascript development, but I have a little toy app with some clojurescript which uses reagent. with the :optimizations :advanced option to the cljs compiler the output is a single js file that is 0.4 megabytes

That is with advanced compilation 😅 In this case I'm using code splitting [1], which is why there are 4 files.

:modules        { :main {:entries #{app.core}
                         :output-to "resources/public/js/compiled/app.js"}
                  :init {:entries #{app.lib.actions.init}
                         :output-to "resources/public/js/compiled/init.js"}
                  :dom {:entries #{app.dom}
                        :output-to "resources/public/js/compiled/dom.js"}
                  :cljs-base {:output-to "resources/public/js/compiled/cljs_base.js"}
                  }

can you not turn on advanced optimizations when splitting?

https://github.com/clojure/clojurescript-site/commit/8affedc604c88dcab75398c1454c390d34df3a7b implies you can I think

The screenshot I showed you was with advanced compilation. The files are much larger without advanced compilation. One of the problems is that the npm code itself takes up 4.9M -- and this has already been compressed by webpack.

the npm code is included into that cljs_base.js file from earlier via advanced compilation. So only 0.6 MB accounts for the app code, while 4.9MB (presumably) is from dependencies.

Now the thing is, a good portion of that code is not needed on page load. The majority of it could be loaded asyncronously on-demand (from a dependency ordering perspective). I'm just not sure how to accomplish this technically yet.

you could use a shadow-cljs flag to look at the output of the build report and see what's taking up space.

^ npx shadow-cljs run shadow.cljs.build-report <your-build-id> report.html

Without knowing too much about your app, it seems like you might want to employ more aggressive code-splitting. Maybe consider splitting by routes if that is an option or splitting out the components w/ heavy dependencies into their own files

I'm also slightly curious what your heavy NPM dependencies are :)

https://github.com/jjtolton/rocinante/blob/master/src/clj/new/rocinante/src/js/index.js more or less @UGGU8TSMC

Antd and materialui are pretty hefty

Yeah going with aggressive code splitting and side loading the npm deps on demand instead of advanced compiling them