Fork me on GitHub
#clojurescript
<
2019-08-16
>
Trevor01:08:43

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

Quest01:08:48

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

Trevor02:08:44

Ah, but following the issues in that template you come to shadow-cljs https://github.com/PEZ/rn-rf-shadow

grav05:08:58

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?

Aklscc07:08:48

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

thheller08:08:48

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

Aklscc08:08:45

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?

thheller08:08:36

clojurescript functions are just javascript functions

thheller08:08:16

so any JS documentations will tell you about all properties

Aklscc08:08:46

Oh, I see. It's great.👍

drewverlee14:08:21

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?

thheller14:08:10

basically: tradeoffs

thheller14:08:59

property based access is subject to renaming in :advanced compilation. so may break if you don't have proper externs

thheller14:08:51

js->clj converts JS data to actual CLJS datastructures. if you plan on using that data for a long time that is totally fine.

thheller14:08:32

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

darwin14:08:12

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

drewverlee14:08:02

Thanks for the help. I'll need to think about this more.

thheller15:08:06

nowadays with externs inference it is pretty much always fine to do property based access

thheller15:08:31

cljs-bean type libs just add a layer on top to let you use CLJS core fns to interop with the data

dnolen15:08:36

@drewverlee fwiw, I think most of what has been done in this space is not meaningful and just muddies the waters

dnolen15:08:21

I would only consider cljs-bean because it does the right thing - it's lazy and just makes JS usage idiomatic

dnolen15:08:12

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

dnolen15:08:53

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

dnolen15:08:09

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

dnolen15:08:33

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

dnolen15:08:44

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

dnolen16:08:55

once you internalize this you see there's only two edge cases. 1) what about APIs outside of what Closure can see?

dnolen16:08:28

We solved that problem with externs inference allowing you to keep the same pattern for program stuff even it comes from somewhere else.

dnolen16:08:08

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

dnolen16:08:39

Mike Fikes solved that for you, use cljs-bean

dnolen16:08:46

we might pull in something like cljs-bean at some point - but in the mean time you know where to go

drewverlee19:08:01

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