Try https://github.com/davidsantiago/hickory

re-html-template also has that, but it is clj side functionality https://github.com/tatut/re-html-template/blob/master/src/re_html_template/parse.clj

can be used as macro in cljs, but not runtime

It's pulled in by fulcro-rad, which has the exact same deps I just updated to: https://github.com/fulcrologic/fulcro-rad/blob/develop/deps.edn So something weird must be going on here

Some libraries might still be using goog.object without requiring it, relying on it implicitly being there. A recent version of CLJS has removed that, but there's a flag to restore that feature if you need it: https://github.com/clojure/clojurescript/blob/master/changes.md#changes-1

Also, just in case - don't specify CLJS version when using shadow-cljs. Instead, use the version that shadow-cljs provides - this way, you'll avoid potential conflicts which can be rather hard if not impossible to circumvent.

Thank you 🙂, this is indeed the issue! Adding :global-goog-object&array true to the shadow-cljs compiler options fixes it. So it's a bug in cljc.java-time:0.1.18 introduced by clojurescript:1.10.914. For others finding this later, here are some additional links: • https://ask.clojure.org/index.php/11274/cljs-3330-has-broken-goog-object-get • https://clojurescript.org/news/news#_google_closure_library_goog_module_global_access • https://clojurescript.org/news/2021-11-04-release#_google_closure_library_goog_module_global_access • https://clojurescript.org/reference/compiler-options#global-goog-object-ampersand-array • https://shadow-cljs.github.io/docs/UsersGuide.html#compiler-options

I think you must be pulling in an older version bc cljc.java-time:0.1.18 was released to address this issue ( goog.object is explicitly required)

huh, fair enough. sorry for the confusion. I just realized it's even stated in the commit message of fulcro here: https://github.com/fulcrologic/fulcro-rad/commit/d0bd026afc4a3281294cbb952c141d2d8762337b. Maybe something else is overriding this with an older version, I'll check the dependency tree

no worries. probably the first time cljs upgrade causes such issues. and hopefully last

well, you were totally right. even though the latest fulcro-rad pulls in cljc-java-time 0.1.18 it doesn't end up in my classpath. so the old version is still there. Guess I try to wipe the .m2 cache and see if that makes a difference

Better yet, inspect a proper dependency tree and see what overrides the dependency. If you're using deps.edn, you can use clj with -Stree or, if that doesn't give enough details, with -Strace and check the resulting trace.edn. Also, clj has its own cache - it's more likely to blame than ~/.m2, unless someone replaced some artifact without changing the version or you yourself put something in .m2, maybe via some tool.

Yeah, I'm on it, .m2 wasn't to blame. I see in my trace.edn the same thing as in the picture above, the latest fulcro-rad pulls in the wrong/old java-time for some reason. So .cpcache in my project is my next target. Thanks for your help guys, this is getting weird

I think it's an issue with fulcro-rad. Compare this line: https://github.com/fulcrologic/fulcro-rad/blob/develop/deps.edn#L12 to this line: https://github.com/fulcrologic/fulcro-rad/blob/develop/pom.xml#L119 In other words, they didn't regenerate their pom.xml after changing deps.edn. Feel free to submit an issue to their repo. :)

well, deleting .cpcache didn't do anything as well. So i guess the issue is somewhere else

Ah damn, i didn't notice @U2FRKM4TW, that must be it!

(I assume that pom.xml takes precedence over deps.edn when you use tools.deps - I don't actually know that for sure)

Finally! Updating the pom.xml in a local fork of fulcro-rad fixed it. Now the correct version is pulled in. So yes, the pom.xml takes precedence over a deps.edn . (I just found it mentioned here for Local jar attributes: https://clojure.org/reference/deps_and_cli#_dependencies) What a journey, I learned a lot today

As a guess - if you use git coords, perhaps the pom file is not used. Unless fulcro-rad has some necessary build process, you could try that instead of having to use a local fork.

I made a small PR with the updated pom and it's already released :) But I'll try the git cords, cause now I'm curious! Thanks again for your help, and sorry again to @U051B9FU1 for jumping to conclusions at first

hey no worries. glad you got it sorted

IIRC all option you pass to the request will be passed along to transit/writer

Try doing that, it should mostly work!

If not, please create an issue and I'll be happ y to look into it 🙂

That was quick 🙂 We will try that, thanks!

From looking at the code, I get that if in the opts there is no value for the key `:transit-json-writer `, it uses the default writer I linked, else you can provide your own. Still validating, but looking good, thanks again!

Yeah just checked the code, to be more precise: pass in your custom transit-json-writer in the request body like a key :transit-json-writer (t/writer :json {:handlers....}

Yup exactly!

I'll add it to the docs thanks!

Thank you

Added https://github.com/lambdaisland/fetch/pull/16

Awesome 🙂

fyi, there is now a #transit channel ...

Already joined 😉

Btw. Your solution worked for us Mitesh like a charm. After some fixes and learning on our side. Thanks ✌️:skin-tone-3:

Glad to hear that!

I would look for a more recent one. That one uses a quite old version of CLJS:

cljs.user=> *clojurescript-version*
"1.8.40"

With that being said, I couldn't really find one...

Actually, if you aren't in a hurry, I might deploy one soon, assuming the process isn't too rough.

I've used this one: http://app.klipse.tech/ (It is on version "1.10.520")

I guess that isn't a REPL though

This is repl-ish:https://crepl.thegeez.net

Oh, it uses 1.10.520. Neat, thanks!

This is a REPL that runs interpreted CLJS via SCI: https://babashka.org/xterm-sci/ So not the official one, hopefully still cool. Just updated to the latest shadow release.

@U2FRKM4TW you rock! Thanks!

Two ways: • Request the routes with AJAX • Embed the routes in a static resource that you serve - I usually use some <meta> or <script type="text/transit+json"> in my index.html for that, which I later read in CLJS code Regarding where to store it - unless the routes change after you have set them up, I don't think you need to store them. Just get them and set them up like you do it usually.

I would look at how other projects do it, like djblue/portal, re-frisk, cjls-devtools, re-frame-10x,...

@U2FRKM4TW thank you, portal looks great

Is that the one in core.cljs.cache.aot.json? Should be loaded, let me check.

There's data that looks like this.

And the original data in the core.cljs.cache.aot.edn doesn't have a mention of defn.

To give more details - I'm trying to port the code of to a modern version of ClojureScript. Originally, it uses Boot with some ancient plugins, so I decided to also migrate it to shadow-cljs. Given that the REPL there is the source of CLJS code, it sounds like a :target :bootstrap build is not needed. And everything seems to be buildable with just :target :browser.

what gave you that impression? :target :bootstrap AND :browser are both most definitely needed

see https://code.thheller.com/blog/shadow-cljs/2017/10/14/bootstrap-support.html

Yeah, I think I misunderstood that article... Do you have any clue how the original code at https://github.com/Lambda-X/cljs-repl-web works at all then? It just extracts the core.cljs.cache.aot.edn from the CLJS jar and loads it via cljs/load-analysis-cache! in the browser. And yet stuff like defn works.

Alright, the method you describe in the article worked immediately, thanks. :) Still wonder why their original code works though... Maybe things were different in the age of CLJS 1.8.40.

things are different in plain cljs yes. but it inlines cljs.core analyzer data as code which makes it about 2x larger and slower to load

plus :bootstrap solves the issue of pre-compiling other namespaces as well. and providing the ability to access react and stuff

Actually, it doesn't inline it! It loads it via XHR. Having other namespaces does sound useful.