What I've found useful when working with channels (or even functions that never supposed to throw) is to always use a map as value with keys such as :result and :error, and then destruct the value after taking it out from the channel, e.g. something like: (let [{:keys [result error]} (<! channel)] (if error ;; error ;; else handle result))

I see, so ya in JS it's better to wrap things to know the difference between error and success then?

It sounds like your logging setup is responsible. Figure out what io.undertow.websockets.core.request uses for logging, find out where to configure it, and redirect those messages to a file or just disable them.

Any tips where/how to start looking? I checked all my explicit logging calls and none of them could produce that message.

Undertow documentation and source code. :)

Seems like this is the line that logs that particular message: https://github.com/undertow-io/undertow/blob/2abb6a2822c6a97904bba4d4b7a601b8e95c4122/core/src/main/java/io/undertow/websockets/core/WebSocketLogger.java#L52

Thank you very much 🙂 Now on to figuring out how to configure it

I'm using Logback and seems like its configuration is respected - I get the same messages as you, but in my case they're redirected to the file I have specified.

This is the configuration that I use: https://github.com/juxt/edge/blob/master/lib/edge.logging.dev/src/logback.xml

Oh, that is even part of Luminus. Goes to show that I still don't know most of the pieces…😅 Thank you very much for your help! I think I'll be able to figure out the rest.

The issue is the code itself - you recreate the atom on each evaluation of the for's body.

And given that you're probably using Reagent, you should read about form-2 components and reagent.core/with-let. Those are the things you should be using to preserve state between renders.

Ah Because the for-loop isn't executed just once on page load but repeatedly:man-facepalming: I'll read up on form-2 components and with-let, thank you. Incidentally is there a simple way in re-frame to do this (it seems overkill to make a new event just for this)?

"To do this" - what exactly?

Ah, to expand a card. Yeah, you just don't use re-frame machinery for that, unless you treat the card state as a part of your app's state.

Roger

Thank you for your help

Hmmm… With with-let I'm getting an error about the same with-let being used multiple times within the same reactive context (still renders fine but the buttons don't work). When trying to wrap the component into an inner fn it returns a warning that functions are not valid react childs (component doesn't render at all; maybe because the component I'm trying to create already is inside a form-2 component? I would've thought they could be nested though) Would I need to restructure the entire document for this to work?

What's the code that gives those warnings/errors?

I put the body of the for-loop into its own function now:

(defn facility-card [name city state zip country]
  (r/with-let [visible? (r/atom true)]
    ;; (fn [name city state zip country])
    [:div.card
     [:header.card-header
      [:p.card-header-title name]
      [:button.card-header-icon {:on-click (swap! visible? not)}
       [:span.icon>i.fas.fa-angle-down]]]
     (when @visible?
       [:div.card-content
        [:span.locality city]
        [:br]
        [:span.region state]
        [:br]
        [:span.postal-code zip]
        [:br]
        [:span.country-name country]])]))

Yep, I'm stupid I called the component with () instead of []

And then how did you use facility-card?

Ah, right - just got to your last message. :)

Works just fine now

I need more coffee…

Once again, thank you for your help (at this point I should have a keyboard macro for that sentence)

Are you using shadow-cljs?

yes

Add :output-feature-set :es5 to the JS compiler options.

i already have es6

should I go back to es5

@U05224H0W It's around the fifth person with this error that I see. Do you think it would be possible to somehow autodetect it? Or, maybe, just suggest :output-feature-set :es5 if the default :es6 fails?

@U01F1TM2FD5 Yes.

I'd rather figure out what the actual problem is. can't really autodetect runtime failures, or at least can't think of a reliable way

just one of those issues that isn't easy to figure out. already spent a couple hours on it but didn't get anywhere

looked into it a bit more. the correct fix is setting :js-options {:entry-keys ["module" "browser" "main"]} apparently. otherwise you end up with "node" code which appears to be broken

Oh, so even though :es5 seems to work on the surface, it might actually be broken without those :entry-keys?

no, don't set :output-feature-set at all

I still don't have a clue why it breaks with es6 and not es5 but for some reason circularRotateKeyframe = keyframes is turned into (0, _system.keyframes)

that (0, ...) trick is usually used to call stuff in the global scope. I don't know why they do that, must be something babel is doing

to me it looks broken

guessing it has something to do with strict mode

Gotcha. Thanks!

I might need to revisit the decision of keeping commonjs the default at some point

Greetings from the future! Sorry to bump a dead thread but I'm running into this same issue (only my error is: SyntaxError: Identifier 'global' has already been declared. I've tried the suggestion above to no avail. Switching to an :es5 feature set solves the issue completely. Any ideas? Seems to still be an issues with ESM imports.

:output-feature-set :es8
:js-options         {:entry-keys ["module" "browser" "main"]}

if you have a reproducible case I can look at it

I don't think I fully understand what you mean but there are extent-protocol, extend-type, and you should be able to extend a protocol to support the type js/Object as the default implementation.

Just name the default implementation something else and make it not depend on any protocol, like default-ask.

yeah that'll work, I'll do this if it's the only way

there's probably no smarter way right

This is the smart way, because it's the simplest one. :) This is not the first time this question is asked, although usually it's asked in #clojure.

okay, thanks a lot for yout time then!

In more generic words: don't do protocol dispatch when you know the exact implementation you need.

yeah I should've probably asked in #clojure, I thought that maybe there would be some clojurescript specific magic

yeah no I'd say it's a natural pattern, super in Java is an example of this

It's a natural patterns for inheritance. Protocols are a different thing.

yeah, you're probably right