Fork me on GitHub
#clojurescript
<
2020-02-25
>
elatedpixel01:02:21

has anyone used "framer-motion"? I'm using shadow-cljs for my build and installed framer-motion with yarn but I can't figure out how to actually use an element... motion.div for instance. I'd love some help!

dpsutton01:02:09

Are you familiar with interop with react components?

elatedpixel01:02:19

I'm reading up on this now - do you have any suggested (curated) reading material on the subject?

dpsutton02:02:34

Read the reagent docs and special attention to their interop guide. Then go read the npm section of the shadow cljs users guide

elatedpixel02:02:16

awesome, thank you!

parens 4
Hojat06:02:26

Hi I'm trying to choose my build tools and I'm stuck What's the difference between figwheel auto reload and shadow-cljs auto reload? Which one is better for development?

EmmanuelOga06:02:53

IMO both shadow and figwheel are great, I've heard shadow could be a bit faster to compile (I'm guessing this only manifests with big projects with a lot of dependencies). Shadow also seems a bit more feature rich when it comes to dealing with NPM and plain JavaScript.

EmmanuelOga06:02:38

what is your objective? Do you plan to work on, say, reagent apps?

EmmanuelOga06:02:53

Someone was just talking about this subject on the shadow-cljs room

Hojat07:02:56

My plan is to work with reagent and how reload functions is very important for me, it can determine which tool I should peak I've read several posts about both but I need someone tell me how they are different, or their functionality is the same and I can choose shadow because of the positive points I've read about it

EmmanuelOga07:02:54

I know is not a great answer but perhaps you should try for yourself. The feature set is so similar it is kind of hard to recommend one over the other. For your use case either one should just work.

EmmanuelOga07:02:16

It is like comparing a Ford Focus vs a Chevy Cruze... you could talk a lot about the similar tech specs but in the end you need to seat in each one, drive them a bit and decide for yourself 🙂

Crispin07:02:46

I use figwheel because I work full stack. I have cljc files that contain both clojure server side code, and clojurescript client side code. I use emacs cider. Cider routes each part to the correct repl. clj to the jvm server. and cljs to the figwheel repl. I run jvm on server side, not node. So shadow-cljs doesn't help me here at all. I would need to have two setups if I used shadow. A leiningen setup. and an edn setup. So I just use figwheel. So it really depends on what you are doing.

Crispin07:02:36

I would say their big difference is shadow-cljs is tuned for javascript. And if you are just doing that, your experience is going to be very smooth. And figwheel is built around leiningen. So if that's what you are used to and using, that is going to be smoother.

valtteri07:02:09

@retrogradeorbit you can do full-stack development with shadow-cljs and it works exactly as you described with Cider.

Crispin07:02:03

Caveat: I haven't used shadow-cljs. A while ago I asked on the shadow-cljs channel how to build uberjars with an embedded js artifact in it, and they said "use leiningen". So I just stuck with leiningen.

Crispin07:02:45

does shadow-cljs now compile uberjars?

markx07:02:47

I’m not 100% sure, but I doubt it ever will. It’s a cljs tool, so why should it compile uberjars? For similar reason, one wouldn’t expect cljsbuild to compile uberjar either, right?

Crispin08:02:07

I'm sorry. I was just asking.

thheller10:02:53

FWIW shadow-cljs will never produce uberjars for the same reason fighweel won't

thheller10:02:15

creating an uberjar is taking files from a directory and putting them into a .jar file

thheller10:02:39

for lein it doesn't matter where those files come from. so it is perfectly fine for shadow-cljs to produce them and then just use lein to package them

valtteri07:02:59

I don’t know if there’s leiningen integration but at least shadow works really nicely with deps.edn.

Crispin07:02:15

does it build uberjars?

valtteri07:02:35

And you can use the ‘usual’ tooling with deps.edn to build uberjars. At least that’s what I’m doing.. Let me find an example.

Crispin07:02:13

Cool. would love to see an example.

valtteri07:02:36

The project I’m currently working with is not open-source, but I can copy-paste the relevant files. shadow-cljs.edn (relevant part is :deps)

{:deps         {:aliases [:ui]}
 :builds
 {:app
  {:asset-path "/js"
   :modules    {:main {:init-fn app.ui.core/main}}
   :output-dir "resources/public/js"
   :target     :browser}
  :cards
  {:asset-path       "/js"
   :modules          {:main {:init-fn app.ui.cards.devcards-runner/main}}
   :compiler-options {:devcards true}
   :output-dir       "resources/public/js"
   :target           :browser}
  :test
  {:main      app.cards.test-runner/main
   :output-to "out/test.js"
   :target    :node-test}
  :e2e
  {:ns-regexp "e2e.*"
   :output-to "out/e2e.js"
   :target    :node-test}}
 :dev-http
 {3000
  {:root      "resources/public"
   :proxy-url ""}}
 :nrepl        {:port 3333}
 :source-paths ["src"]}
deps.edn
{:paths ["resources" "src"]
 :deps
 {org.clojure/clojure         {:mvn/version "1.10.1"}
  com.cemerick/url            {:mvn/version "0.1.1"}
  metosin/reitit              {:mvn/version "0.3.10"}
  metosin/jsonista            {:mvn/version "0.2.5"}
  metosin/spec-tools          {:mvn/version "0.10.0"}
  metosin/ring-http-response  {:mvn/version "0.9.0"}
  clj-http                    {:mvn/version "3.10.0"}
  migratus                    {:mvn/version "1.2.7"}
  ring/ring-jetty-adapter     {:mvn/version "1.8.0"}
  org.postgresql/postgresql   {:mvn/version "42.2.9"}
  seancorfield/next.jdbc      {:mvn/version "1.0.12"}
  com.draines/postal          {:mvn/version "2.0.3"}
  buddy                       {:mvn/version "2.0.0"}
  com.cognitect/transit-clj   {:mvn/version "0.8.319"}
  com.cognitect.aws/api       {:mvn/version "0.8.408"}
  com.cognitect.aws/endpoints {:mvn/version "1.1.11.699"}
  com.cognitect.aws/s3        {:mvn/version "784.2.593.0"}}
 :aliases
 {:ui
  {:extra-deps
   {thheller/shadow-cljs    {:mvn/version "2.8.83"}
    reagent                 {:mvn/version "0.8.1"}
    devcards                {:mvn/version "0.2.6"}
    cljs-ajax               {:mvn/version "0.8.0"}
    metosin/reitit-frontend {:mvn/version "0.3.10"}}}
  :test
  {:extra-paths ["test"]
   :extra-deps  {org.clojure/test.check {:mvn/version "0.10.0"}}}
  :dev
  {:extra-deps {}}
  :depstar
  {:extra-deps
   {seancorfield/depstar {:mvn/version "0.3.4"}}}
  :runner
  {:extra-deps
   {com.cognitect/test-runner
    {:git/url ""
     :sha     "76568540e7f40268ad2b646110f237a60295fa3c"}}
   :main-opts ["-m" "cognitect.test-runner"
               "-d" "test"]}}}
So I’m using depstar to build uberjars. clojure -A:depstar -m hf.depstar.uberjar server.jar

Crispin07:02:12

This looks good. I will give it a try.

valtteri07:02:29

There’s also support for leiningen

valtteri07:02:25

Then you can just cider-jack-in-clj&cljs and select ‘shadow’ as both clj and cljs repls.

markx07:02:52

For myself with a more JS background, I just feel shadow-cljs provides a much more intuitive experience. Plus you can just directly use npm packages.

valtteri07:02:07

moved to thread

Crispin07:02:29

flood warning

valtteri07:02:28

Sorry for the flood. I’m bad at predicting when slack decides to collapse longer chunks and when not.

Crispin07:02:56

slack threads are useful for this

Yefim M07:02:34

Hi, would it be possible to update the https://github.com/clojure/clojurescript/blob/master/project.clj to use latest com.google.javascript/closure-compiler-unshaded - the current one has dependency on protobuf-java-3.0.2.jar that has CVE-2015-5237 (yes, I suspect this is not relevant in this context but still better be safe than sorry)

markx07:02:47

I’m not 100% sure, but I doubt it ever will. It’s a cljs tool, so why should it compile uberjars? For similar reason, one wouldn’t expect cljsbuild to compile uberjar either, right?

Audrius11:02:29

Hello. I have such reader registration call (cljs.reader/register-tag-parser! 'foo identity) after this I call (cljs.reader/read-string "#foo [1 2]") and it works, but #foo [1 2] does not. Why? 😮 I use [org.clojure/clojurescript "1.10.597"]

p-himik11:02:34

I don't know all the details, but I think that's because reading something != evaluating something. You probably need this: https://clojuredocs.org/clojure.core/*data-readers*

Audrius11:02:36

do you think if I add data_readers.clj to a dependent project it will still work?

p-himik11:02:53

So A depends on B, and you want to add a reader tag parser to A so you can use the tag in B? A really smelly idea, don't do that. Also, if you need it in CLJS, just the CLJC file, not CLJ. I think.

Audrius11:02:34

how did you learn about these reading and evaluation so good? Any good books ar something?

thheller11:02:34

don't use data readers in code. just call functions instead. (foo [1 2]) is not that much more code and will have better tool support and not break the compiler in weird ways.

p-himik11:02:15

@UU0EZB7M3 Listen to thheller, don't listen to me. :)

p-himik11:02:14

@U05224H0W One potentially legitimate usage - something like the spyscope library. Also, how can the compiler be broken with custom data readers?

thheller11:02:46

by returning stuff the compiler doesn't understand

thheller11:02:00

or doing weird side-effecty stuff that has race conditions

p-himik11:02:00

Wouldn't that be true for regular macros as well?

zilvinasu11:02:30

Hey, anyone have some links to some example project, where I could see the style of how tests are structured in the project ?

.
├── main
│   └── calculator
│       └── app.cljs
└── test
    └── calculator
        └── app_test.cljs
kind of thinking if this makes any sense ?

Audrius11:02:22

I would create a project from a relevant template and observe the structure there.

zilvinasu11:02:10

tried couple of them for reagent, none of them generated a test path

zilvinasu11:02:01

ah thanks a lot, pretty much similar to what I did

👍 4
Hojat13:02:21

https://clojurians.slack.com/archives/C03S1L9DN/p1582612106059600 I asked a question but didn't get an answer to the real problem. What's the reload differences? Thanks

p-himik13:02:51

I did not see any difference.

Drew Verlee15:02:56

What are the circumstances where ->clj bean can't effectively wrap a javascript object? This would seem to be one:

(-> @debug ->clj :flow)
;; => nil

(.-flow @debug)
;; => "standard"
But i suppose i don't understand where it does and doesn't work.

Drew Verlee15:02:59

and then later... (.. foo -x -y) doesn't work but. (:y (->clj (.-x foo))) does.

p-himik17:02:16

What's debug? Do you use the advanced optimization?

p-himik17:02:35

And what is foo?

Drew Verlee17:02:40

there both javascript objets. How could i find out more?

p-himik18:02:44

Do they have a constructor? What is foo.x?

p-himik18:02:25

You can just print the values to JS console if you develop for a browser. If you develop for Node, you can inspect the variables after hitting a breakpoint.

p-himik18:02:35

Assuming you're using an IDE, that is.

unbalanced18:02:46

Does anyone have any suggestions for monitoring/reporting on client-side cljs code? i.e., let's say the back-end team makes a change to an API and changes the spec sufficiently that it causes an unrecoverable error in the browser (on ajax calls, for example). Or maybe just a backend service is broken. Ideally I'd like to find out about this before the users do or at least at the same time as the first user does. Does anyone have any suggestions for how to deal with this?

p-himik18:02:00

There are different services out there. I'm using Rollbar, for example.

p-himik18:02:20

Of course that will only show errors that some users have already encountered. To catch such errors before you actually deploy something, I don't think there's any other way than to create and run integration tests.

👍 8
jjttjj19:02:44

Is there a way to bind cljs.pprint/**print-miser-width** ? (`binding [cljs.pprint/*print-miser-width* 80]...)` results in

cljs.pprint/*print-miser-width* not declared ^:dynamic

dnolen19:02:51

@jjttjj we should probably open a issue to mark any earmuffed vars as dynamic in the pprint ns

dnolen19:02:10

also that's just a warning - it should work

👍 4
Luis C. Arbildo22:02:18

I'm new in Clojure and I'm try Hellix, but a have a doubt about the operator (..)

Luis C. Arbildo22:02:22

here (d/input {:value name :on-change #(set-state assoc :name (.. % -target -value))

Luis C. Arbildo22:02:55

currently what do (..)?

Luis C. Arbildo22:02:51

oh thanks, I had searching /cljs.core/.. and getting error

lilactown22:02:05

hehe, it took me awhile to find it as well

💯 4
Luis C. Arbildo22:02:38

Is like (-> of clojure

lilactown22:02:34

it provides chaining of property access

Michael J Dorian22:02:40

Is there a defacto standard cljs+react situation currently? I'm seeing both reagent and om.

lilactown22:02:09

reagent is the most mature and widely used, there are another of others with various amounts of features / selling points

lilactown22:02:26

Om (Next) is basically abandoned

p-himik04:02:15

Is there any backstory that you know of?

lilactown04:02:51

Not that I know of, i think most people have just moved on

lilactown04:02:24

Fulcro is the spiritual successor of Om Next afaivt

👍 8
✔️ 8
fricze11:02:43

Om (Next) was great exploratory project. @U050B88UR showed us the light, and other people followed. It was huge when it first appeared, because it presented bunch of great ideas about organizing UI, data-heavy apps. Now we have Fulcro, that is better designed and have better fullstack story, state-machines and whatnot. Also React with GraphQL are moving on, so you need thinner and thinner ClJS wrappers over React. I think exploration was main Davids’ goal with Om and, surely, he succeeded in it

Michael J Dorian22:02:53

Awesome, I'm new to react so I just want the popular one 😁 thanks

👍 4
fricze11:02:00

With latest React changes you may be interested in https://github.com/Lokeh/helix It’s minimal React wrapper, that allows you to use React hooks, reducers and effects. Not popular yet, but with React evolution, thinner wrappers might be the way