This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (3)
- # beginners (106)
- # boot (18)
- # calva (1)
- # cider (43)
- # cljs-dev (45)
- # cljsrn (2)
- # clojure (29)
- # clojure-dev (10)
- # clojure-europe (2)
- # clojure-italy (117)
- # clojure-nl (17)
- # clojure-spec (56)
- # clojure-uk (41)
- # clojuredesign-podcast (12)
- # clojurescript (35)
- # community-development (6)
- # cursive (27)
- # datomic (12)
- # emacs (9)
- # fulcro (6)
- # graalvm (52)
- # instaparse (6)
- # klipse (3)
- # leiningen (11)
- # lumo (1)
- # off-topic (16)
- # pathom (31)
- # re-frame (10)
- # reagent (26)
- # reitit (3)
- # shadow-cljs (67)
- # sql (4)
- # tools-deps (1)
I'd be interested in knowing this myself... I have an Android re-natal app that could use a rebuild. Seems that shadow-cljs is an option these days, but don't know enough to say more
Expo keeps coming up in my googling: https://docs.expo.io/versions/latest/guides/using-clojurescript
Ah, but following the issues in that template you come to shadow-cljs https://github.com/PEZ/rn-rf-shadow
If I were to make all the various
require statements in clojurescript (`cljs.nodejs/require`,
js/require and the
(:require) macro) look in additional dirs for node_modules (eg
/etc/lib/node_modules), how would I go about doing that?
So there is something that has been bugging me for a while and i'm going to type it out here in hopes that either i'll finally understand it or someone will jump in and graciously explain 🙂.
0. JS->CLJ & clj->JS : easy, but rarely used because its too expensive.
1. property access : e.g
(. js/document -title)
2. aget/aset: mostly serve as a distraction as most guides immediately tell you not to use them as there for arrays.
.: I assume these are core supported (included) methods. (the later is just property access again?), Some guide points out this doesn't survive "advanced optimizations"
5. clj-oops: This feels like the goog.object ns but as far as i can tell not using it. If the readme compares them somehow i'm missing it. I have used this library but never done a full read through. I'll need to do that.
6. cljs-bean: includes another version of ->clj and ->js
I'm guessing their are a dozen more libraries. Here is my over arching question, is there a root cause of this divergence? Are some of these depreciated due to changes? Do other ecosystems like <X>js have this same pattern?
The story seems to be that their all trying to be lighter and faster in some context. Is there a way to either make these differences more transparent or even better build an abstraction that can encompass them?
property based access is subject to renaming in
:advanced compilation. so may break if you don't have proper externs
js->clj converts JS data to actual CLJS datastructures. if you plan on using that data for a long time that is totally fine.
but often people use it just to be able to destructure the data, which is bad and has horrible performance. so cljs-bean serve as a faster alternative which basically is just a proxy over the underlying JS object
5. cljs-oops compiles down to aget/aset by default, but you can configure it to use goog.object instead: https://github.com/binaryage/cljs-oops/blob/master/src/lib/oops/defaults.clj#L10-L11 here is the implementation: https://github.com/binaryage/cljs-oops/blob/master/src/lib/oops/codegen.clj#L65-L73
nowadays with externs inference it is pretty much always fine to do property based access
cljs-bean type libs just add a layer on top to let you use CLJS core fns to interop with the data
@drewverlee fwiw, I think most of what has been done in this space is not meaningful and just muddies the waters
I would only consider
cljs-bean because it does the right thing - it's lazy and just makes JS usage idiomatic
(. ...) and
(.- ...) is about program stuff - library apis, object methods, properties of objects returned from libraries you're requiring into your program
once you internalize this you see there's only two edge cases. 1) what about APIs outside of what Closure can see?
We solved that problem with externs inference allowing you to keep the same pattern for program stuff even it comes from somewhere else.
we might pull in something like
cljs-bean at some point - but in the mean time you know where to go