This is a small snippet of what I've been trying. The issue I'm getting is that the anonymous function or the workflow function are never getting called.

(-> 
   (.document functions/firestore "users/{userId}/blog/{blogId}")
   .onCreate
   (fn [snap context]
(workflow snap context)
))

looks to me like you are just missing a pair of parens?

(-> (.document functions/firestore "users/{userId}/blog/{blogId}")
    (.onCreate
      (fn [snap context]
        (workflow snap context)
        ))

Thanks. Yeah, had missed the extra parens when typing on my phone. Also tried the dot macro outlined at https://medium.com/multis/serverless-email-notifications-with-google-cloud-functions-and-clojurescript-fc58dfea067, but log statements inside the workflow fn aren't being called in either approach. I ended up replacing the create trigger via promises in a different spot on the code, which resolved the issue. Wonder if it had something to do with the Firebase emulator or dep version.

At least it seems to make a difference in the advanced output of the compiler:

math.cos = (function math$cos(a){
return Math.cos(a);
});
math.sin = Math.sin;

But maybe the extra function call is optimized away by the js runtime?

Is there a good benchmarking tool in the cljs environment?

https://github.com/quoll/cljs-math/blob/60084c04b8f92ac8886cbd03875308b5423b456d/README.md?plain=1#L9

most likely the defn variant is more performant

given that the actual use likely generates different code

ie. if the compiler knows it calls a fn it can invoke directly. otherwise it'll do the ifn indirection

Any sort of templating, even regular replace will work if you have full control over index.html.

maybe I should rephrase then: I’ve never worked with clojure/script templating before, so do you have any suggestions on which to use?

If it's just for CSRF token, then templating is an overkill - just use some sentinel value in index.html and use regular string replacement to replace it with the token. If you need something more than just a single token, selmer is a good choice.

a sentinel value is a smart idea, thanks. don’t think i need much more than that at the moment

Because you can call seq on JS arrays, which concat does behind the scenes. Also, just in case - note that (clj->js [1 2]) can be written simply as #js [1 2].

But this (that concat works with JavaScript arrays too) is undocumented behavior, right? I guess it's better I don't rely on this?

The source of my doubt is that I was working with JavaScript Promise.all() and using js->clj and clj->js but now I realized that it seems to work even without those explicit conversions. For example, it seems Promise.all() works even when passed a ClojureScript list. I see Promise.all() https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all. Do ClojureScript lists implement the JavaScript iterable protocol?

yes, clojurescript data structures are iterable

Also, your doubt is caused by an observation of the behavior in a "different direction" - using CLJS data structures with JS functions. While your initial question is about the reverse - using JS data structures in CLJS functions. And in general, given that seq works on JS arrays, I think it's safe to expect that seq-processing functions to also work in JS arrays, and for that behavior to remain there.

it's not documented well, but it is expected and changing it would be a breaking change, which generally doesn't happen

Yes, @U2FRKM4TW , i understand my original question was about using JS structures with ClojureScript functions (`concat`), and then I asked about using ClojureScript structures with JavaScript functions (`Promise.all()`). Sorry for the confusion. @U4YGF4NGM Which one is not well documented? Using JS structures with CLJS functions, or using CLJS structures with JS functions? or both?

both IMO

it's not obvious from any docs that arrays are seqable, or that vectors are iterable. but they are! and should continue to be

Ok, I wanted to be sure that I was not missing any docs where this was mentioned. Thanks much both for your help!