This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-08-16
Channels
- # announcements (3)
- # beginners (104)
- # 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?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/call
Thank you. It looks like some JavaScript function properties can be used in ClojureScript, which is interesting. Can I see these properties in ClojureScript by some syntax?
ie. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function
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 🙂.
The Myriad ways of doing interopt with javascript seems overwhelming. I'm just going to quickly list the ways i'm aware of.
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.
3. set!, .-
& .
: 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"
4. goog.object namespace: Provides standard functions like get, get-in, only for javascript objects
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
Thanks for the help. I'll need to think about this more.
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
JavaScript doesn't distinguish these cases but we have to - because program stuff gets optimized by Closure
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
Thanks David! I appreciate the insight. I didn't immediately grok everything you said when i read it yesterday (as i was busy with other things) but on rereading it through today what your communicating is very clear. 🙂