Examples: https://github.com/kkinnear/zprint/blob/master/doc/using/library.md

You're probably looking for something like this: https://nextjournal.github.io/clojure-mode/

thanks!

do you have some tips on how to use with reagent?

to swap! a state and insert the source in a atom

Sorry, no. I haven’t used it myself.

I found this to be very hacky 😞

My 2 cents: in the interest of avoiding extra dependencies, I’ve opted against adding extra libs that do interop… perhaps if I’m doing interop I want the code to be ugly and for the code to stand out (sort of like a “here be dragons” sign 🙂 ) … So I think I agree with David Nolen but don’t have a super strong opinion on all the possible combinations of data vs. methods; JS land can be pretty hopeless in that regard, so I don’t think we can make a blanket statement what’s what (like you point out) for myself, I’ve done two very basic functions over goog closure: https://github.com/raspasov/alexandria-clj/blob/main/src/ax/cljs/googc.cljs

Thanks. yeah I think I've taken various different approaches over time and I've come to think the main thing really is to try to aim for some consistency

I think it is worth mentioning why we care about this from the closure-compiler perspective. first noting what it compiles down to after :advanced. (.-foo obj) just results in obj.foo while (gobj/get obj "foo") results in obj["foo"] or even obj.foo if property is known and valid name at compile time. (`:advanced` removes goog.object operations). then following https://developers.google.com/closure/compiler/docs/api-tutorial3#propnames

note that this is also relevant in cases where it ever becomes practical that the WHOLE code can be :advanced compiled. that is including all dependencies from npm as well. then gobj/get uses for code would break because those would not have been renamed

^js hints are only required because not all code is going through :advanced. so if that ever becomes practical you wouldn't need those either.

so as David said. dot access for code, goog.object for data (eg. JSON)

thanks that's a good point against "gobj/get is safer bc no need to get type hints correct" => it's actually not safer bc it may break in future with smarter compilation

not sure we'll ever get to that place but yeah

Related, https://developers.google.com/closure/compiler/docs/api-tutorial3#propnames: > Inconsistent Property Names > Closure Compiler compilation never changes string literals in your code, no matter what compilation level you use. This means that compilation with ADVANCED_OPTIMIZATIONS treats properties differently depending on whether your code accesses them with a string. If you mix string references to a property with dot-syntax references, Closure Compiler renames some of the references to that property but not others. As a result, your code will probably not run correctly. I think this means if you are doing something different from even the other closure-friendly libraries you depend on (e.g., re-frame), you might get wrecked. No?

If you start using JS interop to talk with CLJS then yes, I think. If you stay within CLJS, then no.

@U2FRKM4TW You're probably right, though I think there can be some good reasons to do that sometimes, like perf. Also do you know if record property access is made consistent somehow if you access them in different ways? E.g., (.-myProp my-record) vs (:myProp my-record)

AFAIK all properties that have the same name will be renamed to the same name as well. So if you use (.-myProp my-record) without adding ^js, myProp will be renamed consistently - both at the point of invocation and at the point of record definition.

And keyword record access turns into JS field access anyway.

Ok, right. Just realized also I was thinking about that wrong, because it actually doesn't matter if the prop name happens to match the key name in the minified js output, since the 2 ways of access would go via different mechanisms. (Normal js prop vs whatever the protocol access compiles to, maybe calling a function with a switch).

> And keyword record access turns into JS field access anyway. Ok good to know, though I'm sure it is only if the key can be determined statically

(let [k :myProp] (k my-record)) will also result in a JS field access. All keyword lookups on records turn into a function call that does switch over (name k).

By non-static I was thinking more like this:

(def props (->> [:foo :bar :baz] shuffle (take 2)))
  
(doseq [p props]
  (println p (p x)))

> All keyword lookups on records turn into a function call that does `switch` over `(name k)` 👍:skin-tone-2:

@U05224H0W that’s actually a very good point re: the whole code base through Google Closure possibility (however unlikely it may be)

I just switched all my interop calls to dot syntax 🙂