What’s the best solution for CLJS if I want to convert hiccup to a string? I found hiccups but it seems unmaintained and hasn’t had an update for 4 years or so. It doesn’t seem to support html5 output and it seems like it hasn’t kept up with mainline hiccup.

I'm trying to read EDN over a websocket which works fine until I try to transfer a regex. I recreated the "problem" without all the WS stuuf from a REPL:

> (cljs.tools.reader.edn/read-string (pr-str #"^\d{4}$"))
#error {:message "Unsupported escape character: \\d.", ...

regex patterns are not part of edn, @jacob429

Since they have to be compiled to a platform specific type and it was decided that it differs too much across platforms

If you eval the code, you can wrap strings in (re-pattern) as an alternative, but that may not be best practice

@jacob429 you should look at #C1DV21X9P's regal library.

weird observed behavior. coworker had a node_modules directory from an experiement two years ago with react 16.3 in it. We are cljsjs/react otherwise and hadn't used any node_modules. We updated to cljs 1.10.773 yesterday and don't use the bundle target. Clojurescript still put our standard cljsjs/react and also the 16.3 react into the build. I was surprised that node_modules was seemingly added to compilation when there was no usage of the bundle target

@dpsutton indexing node_modules predates bundle.

hmm. it wasn't an issue for him until we went from 1.10.439 -> 773. i'll see if i can make a repro

interestingly, (vals "bob") throws under no optimizations and not under advanced which led to a confusing bug 🙂

certainly a garbage in garbage out scenario but was surprising when trying to recreate the issue

A lot changed from 439->773. The change might predate 773/bundle.

right. investigating now. just putting it out there to see if my surprise was warranted or not

hi all, ive got a bit of a confusing one that i cant seem to find any answer to with my google skills. im using reagent, and when i deref an atom using @thing im getting multiple values? (lib/ExpandRefs @lib) Wrong number of args (2) passed to app.lib/ExpandRefs

unfortunately if i log the arguments out to the conosole they arent much use to me to figure out what they are (and then hopefully where they were comming from)

if anyone has any clues i would be most appreciative!! 😄

it’s not possible for @thing to return two values so it is something else in your code

I think the issue is that lib/ExpandRefs is expecting 2 arguments, not receiving 2 arguments. ooops, nvmd

if i add a 2nd argument to lib/Expanded func and log both those i do see 2 “things”

(defn ExpandRefs [lib]
  "repeat transform untill there are no modifications"
  (js/console.log "----\n" lib)
  (fn inner [graph]
    (let [before graph
          after (insta/transform {:ref (fn [r] (lookup-ref lib r))} graph)]
      (cond (= before after) after
            :else (inner after)))))

i can add a 2nd arg to this definition and then the error goes away (but the program blows up anyway )

try checking the stack - the call might be coming from an unexpected place

…. how would one go about that? 😉

also, what does the call look like? could it accidentally be inside -> or doto or .. ?

it is inside a -> yes

:else (-> f ExpandRefs Evaluate ToHtml))))

chuffing new slack input box!!!

i thought the threading macro -> would insert the value as the last arg, so i assumed if i return a 1 arg function it would insert it ?

if you make a breakpoint in your browser js env you can inspect the stack in that debugger

OOOOHHHHH

its a macro!!!

its doing the insertion at “compile” time not runtime 🙂

right

is there a runtime alternative thats a quick switch ?

you can use comp - replace (-> x f g h) with ((comp h g f) x)

that only works for single arg functions though

yeah compose should work for me. thanks a ton, maybe even just the rubber ducking 😄