Fork me on GitHub
#clojurescript
<
2021-04-27
>
athomasoriginal00:04:28

I just start with vanilla interop

(-> (js/promise ...)
    (.then handle-success)
    (.catch handle-error))
If the logic is too complex I would opt for <p! macro. 90% of the time I don’t need anything more though.

athomasoriginal00:04:36

> but what’s idiomatic? Either of the 3 options is fine. For me, I opt for minimal to keep the bundle small and the code “simple”.

gorjusborg01:04:16

nice, thanks

pmooser09:04:16

Is anyone familiar with sci ? I'm trying to start using it in cljs and I'm surprised by how metadata behaves and I wonder what I'm doing wrong.

borkdude09:04:42

@pmooser I'm relatively familiar with it. There is also a #sci channel

😳 1
😁 2
paulbutcher14:04:33

I suspect I’m missing something pretty obvious here: can someone help me spot what? I’m getting a warning in my production build from this line (using ocall from binaryage/oops ):

cljs.core/>, all arguments must be numbers, got [#{js/clj-nil clj-nil} number] instead

  43                 (> (ocall js/Math :abs z) 10))
                     ^---
I expected that I should be able to fix it by adding a type hint like this:
(> ^number (ocall js/Math :abs z) 10)
But I still get the same warning when I do so. What am I missing? Thanks!

p-himik14:04:03

I think that's because ocall is a macro. You don't need ocall here at all: (> (.abs js/Math z) 10). Maybe add ^number there, if it complains again.

paulbutcher14:04:47

I guess having started to use ocall for some of my JS interop, I’ve got used to using it for all of it… I’d still love to understand why the type hint doesn’t work in the code that does use ocall?

p-himik15:04:22

Metadata tags are reader tags. I think what's going on is that that metadata ends up being applied to the (ocall ...) form, but then that form is expanded into some other form because ocall is a macro, and macroexpansion process does not retain metadata.

paulbutcher16:04:23

Ah! That makes sense. Thanks 👍

manutter5120:04:19

I just posted a real stumper in #re-frame, but the more generic CLJS part of my problem is that lein cljsbuild once seems to be copying a file into resources/js/out/... that is not the file as it exists in the dependency I’m require-ing. I’ve done lein clean, I’ve deleted resources/public/js/out, I’ve even tried deleting ~/.cljs/.aot_cache/*, and I still get a crippled version of the file. What’s really weird is that this started happening after upgrading from a really old version of re-frame-10x to the latest version, however checking the git history of the file in question shows that the crippled version has never been checked in (and *I* certainly am not removing the code that I need to compile it!). So where is this crippled version coming from? Is there some other cache somewhere I can purge?

manutter5120:04:25

Alternate version of the question: lein cljsbuild once is copying day8.reagent.impl.component from somewhere, but the file it’s copying is very clearly not the version of the file that exists (or ever has existed) in the repository, so where else could it be coming from?

thheller20:04:15

@manutter51 run lein repl then (require ') and ( "day8/reagent/impl/component.cljs") (or maybe cljc). that will tell you where exactly that file is from

manutter5120:04:09

ok, let me give that a shot

manutter5120:04:06

Oho! ~/.m2/repository/re-frisk/re-frisk/1.5.0/re-frisk-1.5.0.jar!/day8/reagent/impl/component.cljs Now that’s something I’d have spent a long time sleuthing out! Thanks a ton!