@mfikes annotated a forward declaration with the functions signature in bean. (declare ^{:arglists '([x])} bean?). What’s the purpose of this?

@dpsutton See the note under https://clojurescript.org/reference/compiler-options#static-fns

Oh interesting. New to me. Thanks

I'm rendering hiccup, need to show a String of what I guess you'd call "untrusted data" and I want to "safe escape" it. What's the common method(s) for html-escaping?

... this is in a Reagent context. After some searching it perhaps sounds like Reagent escapes things by default. hmm...

yyyyyep. Sorry for the interruption. Brain too used to the non-Clojure ways of making html, assumed burden of escaping was on me.

Hi, I am trying to use Bidi + Accountant for client-side routing and after clicking on links, the address changes in the navigation bar correctly. When I use history buttons, the address changes, but nothing changes in the app. The setup I have:

(accountant/configure-navigation!
    {:nav-handler       #(rf/dispatch [:app-state/changed-route %])
     :path-exists?      #(b/match-route routes/routes %)
     :reload-same-path? true})

I'm curious, why is macroexpand a macro in ClojureScript?

@oskarkv Perhaps one (unsatisfactory) answer is that it cannot be a function.

Yes, quite unsatisfactory

🙂

If it were a function, it would exist at runtime (in the JavaScript target environment, where the Clojure compiler doesn't exist—at least not in JVM-based ClojureScript.)

@oskarkv Here is a post making use of self-hosted ClojureScript to write a version of macroexpand that is indeed a function. It might help in thinking about the JVM ClojureScript case: https://blog.fikesfarm.com/posts/2015-09-05-runtime-macroexpand.html

@mfikes thanks

Re-reading that article, I failed to point out that, even though this lets you have a function version of macroexpand in your code... it causes the entire compiler to be brought with your code into your target environment. 😜

Hm I read that "ClojureScript namespaces can require macros from the selfsame namespace, so long as they are kept in different compilation stages. So, for example a foo.cljs or foo.cljc file can make use of a foo.cljc or foo.clj file for its macros." here https://clojurescript.org/about/differences#_macros But when I tried to make a macro in a cljc file, and :require-macros it from a cljs file the macro didn't work. What did I do wrong?

And about that "so long as they are kept in different compilation stages", well how do I know?

"the macro didn't work" isn't nearly enough info to know why it didn't work and what might need to change

What happened when you tried to use the macro?

Sorry, I restared my Emacs and don't quite remember what I did, but I might have made a mistake. Never mind for now.

OK, so it seems that if I have macros in some-ns.cljc they work, unless I also have a some-ns.clj file, then the macros in cljc act as functions.

(ns game.core
  (:require
   [game.bla :as b :include-macros true]))

game.core> (b/trice (println 1))
1
1
1
nil
game.core> (b/twice (println 1))
1
(do nil nil)

Here, trice is defined in the clj file, but twice in the cljc file

And, it means that if I have some code that only works in Clojure, and I therefore create a .clj file, then macros that could work in both if I had reader conditionals now do not, since they have to be defined in the .clj file instead of .cljc.

hmm. I’m surprised by that behavior

I thought that if you have some-ns.cljc and some-ns.clj, that the .clj file will be picked over the .cljc one

by the :include-macros / :require-macros

it might be the other way around. but either way I’m surprised that it would load both at all

so if trice is in one, and twice is in the other, I would expect only one to exist

I’m assuming that game.core is a .cljs file

re: reader conditionals, you probably don’t need reader conditionals for macros

you might be surprised by the behavior of a macro using reader conditionals

since most ClojureScript projects use the JVM CLJS compiler, all ClojureScript macros take the :clj path in a reader conditional

since the macro is executed in the context of the JVM ClojureScript compiler

if you need a macro that needs different implementations depending on the target (e.g. if it’s used in a CLJS file vs. a CLJ file) then you’ll need to use something other than reader conditionals within the macro

my 2 cents are: don't ever use .cljc files if you can avoid it. macros are confusing enough as it is, writing them in .cljc is exponentially harder to get right 😛

@lilactown Oh, good to know about the :clj reader conditional

@thheller Hm, except for this gotcha with having both clj and cljc files, what's so hard? 😛

might just be me 😛

isolating macro-only code properly etc

The rule with .cljc / .cljs / .clj files is that a platform-specific file will be loaded in preference to a .cljc file. Applied to ClojureScript, this means that .cljs will be loaded in preference to .cljc for runtime namespaces and that .clj will be loaded in preference to .cljc for macros namespaces.

Hm, I don't like that rule, because as soon as I have something that only works in Clojure, for example, and create a .clj file I have to move all my macros. 😛

Unless I want to have a bunch of reader conditionals in a .cljc

Oh, and if I want my library to work for both clj and cljs, I have to choose either clj + cljs or cljc, I can't mix. 😛