This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-10-27
Channels
- # announcements (10)
- # beginners (95)
- # biff (2)
- # calva (33)
- # cherry (1)
- # clj-kondo (16)
- # clojure (96)
- # clojure-australia (1)
- # clojure-china (1)
- # clojure-europe (42)
- # clojure-filipino (1)
- # clojure-france (2)
- # clojure-hk (1)
- # clojure-indonesia (1)
- # clojure-japan (1)
- # clojure-korea (1)
- # clojure-my (1)
- # clojure-nl (1)
- # clojure-norway (24)
- # clojure-sg (11)
- # clojure-taiwan (1)
- # clojure-uk (1)
- # clojurescript (21)
- # cursive (22)
- # data-science (3)
- # events (7)
- # fulcro (3)
- # graalvm (4)
- # gratitude (6)
- # helix (11)
- # honeysql (7)
- # hoplon (1)
- # introduce-yourself (1)
- # jobs (2)
- # jobs-discuss (16)
- # lsp (15)
- # malli (14)
- # nbb (73)
- # practicalli (3)
- # reagent (8)
- # reitit (5)
- # releases (1)
- # ring (5)
- # rum (3)
- # sci (17)
- # scittle (7)
- # shadow-cljs (22)
- # tools-deps (26)
- # xtdb (9)
Could anybody point me to the cljs equivalent of this weird constructor syntax:
const myWritable = new Writable({
write(chunk, encoding, callback) {
// ...
}
});
I thought it'd be
(def myWritable (Writable.))
(aset myWritable "write" (fn [entry _ next] ((println (:key entry)) (next))))
but it looks like I got something wrong..the write(...
line is a shorthand property notation https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Object_initializer#method_definitions
so something like:
(def myWritable (Writable. #js{:write (fn [chunk encoding callback] ,,,)}))
(require '["stream" :as stream])
(def ws (stream/Writable. #js {:write (fn [chunk encoding next] (js/console.log (.toString chunk) (next)))}))
(.write ws "ping!")
Thanks a lot guys 🙂
What do we think of this line from the shadow-cljs docs?
> It is not recommended to separate source files by extension (eg. src/clj
, src/cljs
, src/cljc
). For some reason this is widely used in CLJS project templates but it just makes things harder to use.
Do you mind giving the pain points?
And maybe a view on why people think its a good idea to split it up?
You navigate between namespaces using either your IDE's capabilities or file tree browsing.
If you don't have an IDE (e.g. when quickly looking something up on GitHub), you have to resolve to file tree browsing.
So, within an IDE, you don't really need those directories - you can just navigate to the right ns. So separation by extension doesn't help here.
And while using a file tree, it's much better to have everything together rather than incessantly switch between 3 directories. "Alright, this CLJS function calls this function which is in that namespace. Ah, crap, it's a macro - now I gotta go to a different dir. Ah, crap, that function is in a .cljc
file, now I gotta switch once again."
As to why people separate those files, I see only 2 reasons:
• Desire to organize, even when that organization is detrimental
• Minimizing the size of an uberjar by excluding the src/cljs
directory. But I'm pretty sure this can be solved by simply excluding all *.cljs
files instead
Flat is good. Generally a good rule of thumb for any data modelling, including source code directories.
I think at some size it's kind of a mess no matter what. You just need to make some kind of decision and learn to live with yourself lol
I used to prefer hierarchies, but at some point I realized that hierarchies don’t make things more ordered, it just makes for more places to look. So better to flatten things out, and only create levels when there’s enough sub-content to justify it. And when you do, group by functionality, not technology.
> group by functionality, not technology Exactly. BTW Sean Corfield has a few posts in his blog on monorepos - definitely relevant for larger projects.
We don't have any .cljc
or .cljs
at work so I don't have much of an opinion on it. Two of the OSS projects I mention are primarily .cljc
and do not separate out the few .cljs
/`.clj` files into different trees.
I think that separation makes sense when you have almost completely separate implementations for a common API in a library (`clojure.core.async` is like this, as I recall) because you end up with the same namespace in both trees -- so they must stay separate.
But in (web) apps, you are rarely going to have that: you'll have some pure frontend code and some pure backend code and some shared code and they won't overlap in namespaces so it makes no sense to have separate trees.
(we may build a ClojureScript app at some point so I may have a stronger opinion at that point, but I suspect I'll be in the latter situation -- web app with no overlapping namespaces)
What I haven't figured out is why anyone would split .cljc into its own folder considering it can have namespaces clashing with both cljs and clj
Not sure what you mean there?
Well for instance, the bootstrap I'm using separates clj, cljs, and cljc. It uses the same namespace for each folder. So clj/app/home
and cljs/app/home
are both (ns app.home)
.
Not a problem if you're only working with clj and cljs. The imports assume it's from their folder. But if you have a third similar namespace, cljc/app/home
, then files from neither clj or cljs can import that cljc file, because they are gonna prioritize their own namespace.
So I'm not sure why anyone would work with a separate cljc
directory with name spaces that could potentially overshadow the other two.
Ah, got it. You mean there's less chance of accidentally blocking a ns if you keep them all in one tree.