Fork me on GitHub
#clojurescript
<
2020-06-03
>
ingesol09:06:20

@bhauman or anyone else who might be interested, I figured it out, webpack config needs this: devtool: 'source-map' to fix problem above

ingesol09:06:00

Source that was directly relevant and helped: https://github.com/aws-amplify/amplify-js/issues/5660

ingesol09:06:16

It affected around 10 of my NPM dependencies, out of about 30. Did not look into the characteristics of the ones that did not work, could do that if any of the core people are interested in solutions to this problem.

kah0ona10:06:25

Hi yall, Question: when my app is compiled, it seems to run in the window scope. Is there a way to like wrap it in a Immediately Invoked Function Expression (IIFE) or similar?

kah0ona10:06:13

because my cljs script is being embedded in websites beyond my control, this is why I ask.

kah0ona10:06:30

ie. it sometimes conflicts with other scripts in there

kah0ona10:06:25

or should I approach this in a different way?

kah0ona10:06:40

Yes it was, :output-wrapper true did it. Thanks rubber ducks!

duckie 12
dazld11:06:03

is there a way to get the closure compiler to output a warning whenever it encounters a js property that isn't defined in an extern? is this even a good idea?

dazld11:06:31

so, if you do a (.-foo x) where x is typed / inferred value, and if foo isn't defined in an extern, it'l let you know at compile time

thheller11:06:24

in shadow-cljs there is shadow-cljs check the-build but it generates very many false positives and a lot of noise so its not super useful. it does warn about all those cases though.

thheller11:06:14

so generally not a good idea for CLJS. only really works if you have fully typed code like the closure-compiler prefers.

dazld11:06:32

we're mostly bashing DOM apis, which should be fully typed

dazld11:06:07

which flags does check-the-build set, @thheller? i'd like to give it a go

thheller11:06:40

well but the CLJS code you are doing this with isn't typed 😛

dazld11:06:01

true true 😉 but we can provide hints

thheller11:06:55

can't really do this without shadow-cljs. its not just a couple compiler options. shadow-cljs also feeds additional info to the closure-compiler. otherwise you'll end up with thousands of warnings for cljs.core alone

dazld11:06:04

something like the *warn-on-infer* for file scope, for example..

dazld11:06:13

we're using shadow, i'll give it a go

thheller11:06:58

shadow-cljs basically just runs the closure-compiler with typechecking enabled (which usually isn't)

👍 4
dazld11:06:20

see what you mean about false positives.. loads of warnings for arity-1 parseInt for example, which I'm not even sure is an error in the browser.. (the radix behaviour should be stable there..)

dazld11:06:53

how about some kind of regex for filtering the warnings? bit like the test ns matching

dazld11:06:25

shadow-cljs check :build --filter=my.app.ns or so

dazld11:06:50

can write that up as a ticket if think it's worth looking at

thheller11:06:04

dunno, in my experience check output is only useful as very last resort. externs inference usually catches most things already so that should be preferred

thheller11:06:53

FWIW the parseInt for example SHOULD always have 10 as the second arg if you want to be safe

thheller11:06:02

> An integer between 2 and 36 that represents the radix (the base in mathematical numeral systems) of the string. Be careful—this does not default to 10!

thheller11:06:19

thats why closure complains 😛

dazld11:06:24

to give a concrete example, i'm upgrading a JS library that renamed a property that exposed a promise from complete to done - promises can be resolved with undefined just fine, so it wouldn't throw any kind of error as if we tried to invoke it as a function.

dazld11:06:42

heh, it's a classic (parseInt) - yay for octals etc.

dazld11:06:52

point taken

thheller11:06:22

well for JS libraries you wouldn't get a warning for this at all

dazld11:06:35

I wrote an extern for it, and provided hints in cljs.

thheller11:06:47

closure can't tell if its complete or done since it doesn't know the type of the value you are operating on

thheller11:06:19

those hints you provided in CLJS are not transferred to be visible by closure

thheller11:06:47

if you mean ^foo hints, only works via :jsdoc hints

dazld11:06:36

(defn thing [^js/myThing x]
  (.-foo x))

dazld11:06:56

so, in this example, .-foo might get mangled?

thheller11:06:08

yeah closure doesn't see that. it just causes shadow-cljs to generate externs for foo

dazld11:06:55

so, shadow will assume that the programmer has done the right thing, and generate an extern for the property foo?

thheller11:06:44

as soon as you add a ^js hint it will be treated as such and collect externs for all property access yes

👍 4
👀 4
4
wombawomba12:06:18

Any recommendations on HTTP client libraries compatible with both CLJ and CLJS? Or am I better off writing something that handles both on my own?

wombawomba13:06:47

To answer my own question, https://funcool.github.io/httpurr/latest seems to be roughly what I was looking for — will give it a shot 🙂

gekkostate16:06:47

Hi all, is possible to add an :after style dynamically? I am using reagent and essentially, I have tried doing {:style {:after {… attrs …}}

lilactown16:06:51

@gekkostate you can toggle a CSS class which has the :after style

gekkostate16:06:23

Yes, that’s a good point. I will try this approach. Thanks!