shadow-cljs 2022-10-12 | Slack Archive

wombawomba07:10:39

Is there a way to get shadow-cljs to never give up on reconnecting the websocket? It's annoying to have to refresh the page every time I'm disconnected from the backend for more than a few minutes.

thheller08:10:04

there is no such option no. how long are you talking?

wombawomba09:10:27

well, anywhere between a few minutes to hours

wombawomba09:10:36

it happens when: • I'm running locally and my laptop goes to sleep. • I'm running against a remote host and my SSH session dies.

wombawomba09:10:42

I see the point in theory (i.e. in production scenarios) of giving up on the websocket, but in practice it only happens during development, and I don't think people would mind if shadow-cljs kept retrying to connect forever when they're developing

thheller09:10:44

it does recover from sleep for me, regardless on how long the sleep was?

thheller09:10:40

I mean I guess it could try to connect forever

wombawomba09:10:02

yeah it doesn't always happen when sleeping

mhuebert10:10:52

When requiring a js namespace with a string require (eg. ["complex.js" as Complex]), using the alias as a type hint (eg (defn angle [^Complex a] (.arg a))) doesn’t have the same effect as eg. ^js and breaks in advanced. Would it make sense to handle it like ^js, since (I believe) Complex would otherwise be treated as something from javascript-land?

thheller11:10:26

it should be ^js not Complex

thheller11:10:59

there is very little logic in the type stuff and even less for :as since that usually means namespace alias

mhuebert11:10:28

ok thanks!

thheller11:10:59

I mean technically I guess it could be changed but I think that change would need to be in cljs.analyzer

Sam Ritchie13:10:29

I was hoping that ^Complex would work since it would have saved me the cljc fork inside the code

Sam Ritchie13:10:01

@U05224H0W is there some way to have a warning emit for spots where inference fails? it does seem that SOME of the non-`^js` tagged spots are fine under advanced compilation

thheller15:10:44

I'm not aware of any "spots where inference fails", besides a couple places in core.async

thheller15:10:27

things that are already part of known externs won't warn. many "common" things are already covered, eg. all DOM things like clientX and whatever

Sam Ritchie16:10:20

I guess I mean spots where not including the js hint causes a breakage

Sam Ritchie16:10:00

(defmethod g/magnitude [::complex] [a]
  #?(:clj (.abs ^Complex a)
     :cljs (.abs ^js a)))

so it sounds like this is what’s required, @U05224H0W, for a cljc file?

Sam Ritchie16:10:32

it’s “coincidence” that both js and jvm share the .abs name so I guess it was cheating to try and share them before 🙂

thheller09:10:44

I checked why the code didn't already handle this. turns out it was just because of a too specific assumption

thheller09:10:23

so (:require ["some-npm" :as x]) and ^x/Complex worked but not ^x. should be fine as of 2.20.5. should be fine with clojure style annotations assuming they can all be resolved the same

Sam Ritchie16:10:18

okay, I took a pass and just made it totally clear by adding ^js all over

wombawomba10:10:49

Should lazy/loadable be called at namespaces' top level, or is it fine to call it when it's used, e.g. in a Reagent component?

thheller11:10:41

should be called in a scope that remembers its state, best is top-level

thheller11:10:35

I mean its not the end of the world to always re-create it

thheller11:10:13

it is safe to pass around as props and stuff but it doesn't have equality semantics

wombawomba11:10:42

alright, thanks

2022-10-12

Channels