Fork me on GitHub
#clojurescript
<
2021-07-02
>
ag06:07:51

I need to add to an existing Clojure (lein) app, a Clojurescript layer. It's been a while since I used Cljs. What's the "recommended" production-ready level approach these days? - Shadow or Figwheel? - If the answer is Shadow, is it better first to convert the lein app to deps.edn? - It's important for me to have two REPLs simultaneously (clj & cljs). Most in my team use CIDER. What do I need to do to be able to just jack-in and have two REPLs?

thheller07:07:49

shadow or figwheel is really your choice. both work. for shadow-cljs you can use lein, deps.edn or keep CLJS completely separate in shadow-cljs.edn. really up to you. Can't comment on Cider but I assume it can connect to a remote REPL even if jacked-in to another CLJ process. shadow can also run embedded into your regular CLJ server although I don't recommend doing that.

ag07:07:20

Last time I tried shadowcljs, I couldn't figure out that aspect - two REPLs at the same time with CIDER. What are the current cons of using Figwheel? Having to deal with cljsjs packages? > shadow can also run embedded into your regular CLJ server although I don't recommend doing that. Could you tell more, why? Or it's too big of a conversation for Slack?

thheller07:07:44

embedding usually ends up in more dependency conflicts than necessary. for example a common one is guava. the closure-compiler depends on a specific version and having datomic on your classpath as well usually ends in a conflict. There is really no reason to have datomic (and its deps) on the classpath when compiling CLJS.

thheller07:07:02

there are also common issues when running tools.namespace and letting that "refresh" too much and unloading parts of the running shadow-cljs instance

thheller07:07:51

IMHO you gain only pain by running it embedded but you can if you don't mind taking some extra precautions regarding conflicts and so on

thheller07:07:29

(the guava conflict for example also happens with figwheel so not really shadow-cljs specific on that one)

thheller07:07:10

can't comment much on the figwheel side of things. if you only use react+react-dom many people actually prefer sticking with CLJSJS since they don't have to deal with npm

thheller07:07:45

with shadow-cljs you must use npm packages but you also gain access to all of them not just the subset available via cljsjs

thheller07:07:04

but you can also use :target :bundle with figwheel which gives you the same access to npm (at the cost of having to deal with webpack or so)

thheller07:07:23

as for the REPL I use Cursive and just connect remotely to my lein repl using the .nrepl-port file and then remotely to shadow-cljs using the .shadow-cljs/nrepl.port file

thheller07:07:53

works perfectly fine. I'd assume cider can do something similar. no clue about the whole jack-in business though, never done that.

weihua09:07:57

I’m using shadow-cljs with cider, and when I eval a print, it’d print the result in my browser repl, which is fine and expected. But is there anyway to also let it print in cider repl as well? (Sometimes i don’t want to switch to browser-repl and back to editor this case)

Apple09:07:16

sounds like you need to start a cljs repl from editor

Schpaa10:07:14

How can I solve an “Error: No reader function for tag object.” Where do I even start looking? I’ve remove all caches, all build-products, even rolled back commits, but this message persists in the console and thats all.

Schpaa10:07:03

main.js:1552 Error: No reader function for tag object. at new cljs$core$ExceptionInfo (core.cljs:11472) at Function.eval [as cljs$core$IFn$_invoke$arity$3] (core.cljs:11504) at Function.eval [as cljs$core$IFn$_invoke$arity$2] (core.cljs:11502) at Function.eval [as cljs$core$IFn$_invoke$arity$variadic] (errors.cljs:37) at Function.eval [as cljs$core$IFn$_invoke$arity$variadic] (errors.cljs:43) at Object.cljs$tools$reader$impl$errors$throw_unknown_reader_tag [as throw_unknown_reader_tag] (errors.cljs:221) at cljs$tools$reader$edn$read_tagged (edn.cljs:372) at cljs$tools$reader$edn$read_dispatch (edn.cljs:72) at Object.cljs$tools$reader$edn$read_delimited [as read_delimited] (edn.cljs:174) at cljs$tools$reader$edn$read_map (edn.cljs:194) env.evalLoad @ main.js:1552 (anonymous) @ main.js:2368

Schpaa10:07:07

I am using shadow-cljs

Schpaa10:07:32

Perhaps I need to reinstall the dev-environment

Schpaa10:07:45

The compiler compiles without any complaints, but this error persists!?!

p-himik10:07:04

I would try looking at that place in main.js. Something is trying to read EDN, and that EDN contains #object for some reason.

Schpaa10:07:12

I don’t know what to look for

Schpaa10:07:48

the error disappeared while just looking at the screen

Schpaa10:07:56

this is not good

Schpaa10:07:21

perhaps the machine is defective, memory etc

p-himik10:07:29

Doubt it. I'd wager on some implicit reliance on something indeterminate. Try changing your shadow-cljs build config so is has :devtools {:loader-module nil}. It should create multiple JS files during development instead of a single file with a lot of evalLoad statements. It will be easier to debug that.

Schpaa10:07:13

No, this machine has defective memory

Schpaa10:07:22

just confirmed it

Schpaa10:07:24

sorry to bother you with this, thanks anyway

p-himik10:07:07

No problem.

nate sire16:07:53

how did you know to infer it was a memory error? Interested because I recently dealt with a different memory problem.

thheller19:07:22

> Error: No reader function for tag object

thheller19:07:33

there never is a reader function for #object

thheller19:07:45

you are trying to parse invalid EDN I guess?

thheller19:07:19

somewhere in the EDN you are parsing you have a #object [Some.Class ...]