Has anyone tried to have docstrings for their compiled JS packages? We're trying to ship a shadow-cljs->js package that is friendly for javascript users and trying to get docstrings to render in VSCode.
Are there any ClojureScript runtimes / platforms (not sure of the common term there -- the JavaScript engine plus whatever is around it for running ClojureScript with a REPL) that enable two or more REPL connections to it simultaneously? I know this is built-in with Clojure on the JVM, but if I understand correctly that is trivial with a multi-threaded JVM. It seems like it would be much trickier with a single-threaded JavaScript runtime.
@andy.fingerhut ClojureScript socket REPLs support that
it wasn't really that tricky
Are there multiple threads handling the multiple REPL interactions outside of the JavaScript runtime? Or are they just all somehow handled in some kind of event loop in a single thread?
there are no multiple threads
but that doesn't really make multiple connections challenging in any meaningful way
I'm not certain if this is the right place to ask this, so if it isn't, I appologize:
I'm trying to understand how reagent decides to re-render components, so if I have something like this: https://gist.github.com/LeifAndersen/037507a44a0945fba2807b0bb63f28d6
In particular:
(defn counter-view [db]
[:h1 (:counter db)])
(defn home-page [db]
[counter (select-keys db [:counter])])
If some part of db
that is not :counter
gets modified, will counter-view
get updated?
And by modified, I just mean another element changes:
(defn default-db []
{:counter (r/atom 0)
:label (r/atom "Count")})
So in this case, say label
gets changed with (reset! (:label db) "foobar")
#reagent is probably a better place.
Okay, by putting println
statements before returning the elements, it 'looks' like only the components with changed atoms are re-rendered.
Okay, another question, I find that functions like this tend to work:
(defn foo [fs]
(fs.readdirSync ...))
Is this actually supposed to be possible, or is it some undefined behavior that just 'happens' to work?Basically, fs
is bound, but fs.readdirSync
is not, unless the .
character is special?
.
just happened to work accidentally mostly. (.readdirSync fs ...)
would be the more correct way but unlikely that the other way will be removed at this point
or if fs
is an alias from a :require
in the ns
then (fs/readdirSync ...)
would also work
Hello friends, I am trying to make this https://clojurescript.org/guides/webpack work, and running into an error: "[webpack-cli] Compilation finished\nasset main.js 644 bytes [emitted] (name: main)\n\nERROR in main\nModule not found: Error: Can't resolve 'out/index.js' in '/path/to/myproject/foo'\n\nwebpack 5.5.1 compiled with 1 error in 35 ms\n",
I run into the same issue myself, when following the https://clojurescript.org/guides/webpack exactly. I think I resolved both issues by changing “out/main.js” in the recommended build.edn
to “./out”.
The “hello world” works at that point; I’m not clear on whether or not this is quite what was intended. It felt odd to have a main.js
file inside a main.js
directory.
I ran into the same issue. Here is the corrected build.edn file:
{:main hello-bundler.core
:output-to "out/index.js"
:output-dir "out"
:target :bundle
:bundle-cmd {:none ["npx" "webpack" "./out/index.js" "-o" "./out" "--mode=development"]
:default ["npx" "webpack" "./out/index.js" "-o" "./out"]}
:closure-defines {cljs.core/*global* "window"}} ;; needed for advance
Specifically, when I get to the `
clj -m cljs.main -co build.edn -v -c -r
stepthats in build.edn
? like you have out/index.js
somewhere when you need "./out/index.js"
webpack is picky about paths
yeah, still no dice 😕
in the webpack config maybe? can't be that many places 🙂
actually no! i missed a spot! you nailed it.
thank you!
Now I run into: > cljs.user=> Exception in thread “Thread-6” http://java.io.FileNotFoundException: ./out/main.js (Is a directory)
I don’t suppose you have any insight there?
gotta be careful with those paths 🙂