Fork me on GitHub

For react native development, re-natal still the way to go?


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


Ah, but following the issues in that template you come to shadow-cljs


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?


what's the meaning of (.call f x y) for cljs function, f is a function.


calls the function f with x bound as this and y as an arg


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?


clojurescript functions are just javascript functions


so any JS documentations will tell you about all properties


Oh, I see. It's great.👍


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?


basically: tradeoffs


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: here is the implementation:


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


also most of this confusion comes from just not starting w/ the right mental model


(. ...) and (.- ...) is about program stuff - library apis, object methods, properties of objects returned from libraries you're requiring into your program


goog.object is about data - dynamic JSON stuff, the key set can't really be known


JavaScript doesn't distinguish these cases but we have to - because program stuff gets optimized by Closure


Closure assumes the key set is known - it's not really dynamic


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.


2) what about performance for the data case if you want your code to look "pretty"?


Mike Fikes solved that for you, use cljs-bean


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. 🙂