Fork me on GitHub
#clojurescript
<
2019-05-21
>
vnctaing06:05:17

Hi, I’m quite new to clojurescript coming from js world, i’m reading about re-frame, feels a lot like redux, but doesn’t create a lot of boilerplate at scale ? Like for any single UI change you have to go through the whole dominos process ?

mikethompson06:05:38

@vnctaing The moment you start using re-frame your sex life will improve, all your skin blemishes will disappear, and your chances of winning either an Oscar or Nobel Prize improves hugely. This has all been rigorously proved (via methods!). Although be aware that some have accused me of bias and it might be best for you to keep reading the docs and drawing your own conclusions :-) But to answer you question, yes, boilerplate reduces (compared to Redux). And, yes, re-frame takes care to ensure that the minimum necessary number of dominoes fall per iteration.

metal 8
😁 4
👏 8
roklenarcic13:05:27

I have a project with shadowcljs, which has a package.json file, which has dependency "react-icons": "^2.2.7". I would like to use these react classes but I don't know how to import them in code. I tried adding:

(:require ["react-icons/fa" :refer [FaBeer]] ....
but I get this error:
{:js-str-offsets [], :js-esm false, :js-imports [], :js-invalid-requires [], :goog-provides [], :js-language "es3", :goog-module nil, :js-warnings [], :resource-name "node_modules/react-icons/fa/index.js", :js-requires [], :js-errors [{:line 1, :column 7, :message "'async' expected"}], :goog-requires [], :tag :shadow.build.npm/errors, :uses-global-buffer false}
ExceptionInfo: errors in file: /Users/roklenarcic/clojure-projects/cards/node_modules/react-icons/fa/index.js
	shadow.build.npm/get-file-info* (npm.clj:531)
	shadow.build.npm/get-file-info* (npm.clj:433)
	shadow.build.npm/get-file-info (npm.clj:568)
	shadow.build.npm/get-file-info (npm.clj:565)
	shadow.build.npm/find-resource (npm.clj:659)
	shadow.build.npm/find-resource (npm.clj:620)
	shadow.build.resolve/find-npm-resource (resolve.clj:109)

dpsutton14:05:27

have you seen the documentation about how to do imports @roklenarcic? @thheller has amazing docs and walks you through how to figure out the correct import

thheller14:05:33

@roklenarcic it looks like the entire library is shipped as JSX code. shadow-cljs does not support JSX code.

thheller14:05:23

ah no hold on. there is a properly transpiled version

thheller14:05:03

try (:require ["react-icons/lib/fa/beer" :as FaBeer])

dpsutton14:05:15

(apologies @roklenarcic i've asked the same question before I knew about these excellent docs)

roklenarcic14:05:56

thheller, that works thanks

vemv15:05:08

(defn foo ^string [^string x])

[(-> #'foo meta), (-> #'foo meta :arglists first meta)]
Why does neither -> return :tag metadata? I can obtain it in JVM clojure It would help me make sure my type hints are doing the thing I think they are, allowing me to write metaprogramming tools, and unit tests for those

mfikes19:05:04

You need to move your return value type hint to be before the function name symbol.

mfikes19:05:37

If you do that, you will get :tag string

mfikes19:05:34

(For the return value.)

mfikes19:05:26

One thing that might be useful for ascertaining what is going on with type hints: https://github.com/mfikes/ilk

mfikes19:05:23

For the argument meta, you just need another first

(-> #'foo meta :arglists ffirst meta)

mfikes19:05:18

If you set *print-meta* true, you'll see this in the in the meta for #'foo:

:tag string,
  :arglists ([^{:tag string} x]),

vemv19:05:53

Promising - Taking a look rn!

vemv13:05:35

Hey there, back at it again

vemv13:05:48

You're right for the ffirst, plain mistake

vemv13:05:19

However, as for the ret vals, doesn't the cljs way break the JVM clj convention?

scknkkrer17:05:07

Has anyone work with Electron ?

scknkkrer17:05:25

I have a couple of newbie questions.

scknkkrer18:05:26

If someone wants to learn about getting started, Electron /w Clojurescript. Message me. I have done it.

thheller19:05:17

@vemv that kind of stuff isn't supported in CLJS. vars don't exist at runtime in CLJS.

vemv19:05:25

But then wow come I can access a variety of metadata keys via var-quote syntax? Is it some kind of sugar?

thheller19:05:36

yes. var is a macro that will create a cljs.core/Var instance with the data from the analyzer

thheller19:05:54

this can only be done with static symbols though so its use is rather limited

vemv19:05:46

I see, thanks! Same story for self-hosted cljs?

thheller19:05:21

self-hosted has access to the analyzer data at runtime so techncially you could do more stuff

vemv19:05:11

Interesting! I might look into using the s-h version, at least for the test suite of my lib. Might let me do the same crazy stuff I do in my JVM suite (testing macroexpansions, var metadata etc)

michal19:05:29

hey, one question regarding cljs configuration. I noticed that in order to have a correctly working code-splitting and modules loaded dynamically (with advanced optimization) :output-to in modules need to start with the same path as :output-dir (which sets directory for temporary files). for example, when :output-dir is "scripts/out" module with {:output-to "scripts/out/blah.js"} config is loaded correcly when required whereas with this config {:output-to "scripts/prod/blah.js"} the URL that modules is being fetched from is really weird (contains absolute path like http://Users/xxx/projects/yyy/scripts/prod/blah.js). I found the same problem described in boot (https://github.com/boot-clj/boot-cljs/issues/174#issuecomment-328139572), but my question is - is there any way to store generated modules out of :output-dir?

dnolen20:05:29

@michal probably a question for the #boot channel. re: ClojureScript's own behavior - should probably emit a warning about :output-dir not matching :output-to

michal20:05:51

@dnolen well, actually my problem is not related to boot (I just found their ticket by chance). let me explain why I need such a combination (modules generated outside of output-dir), maybe my thinking is somewhere wrong. I would like to generate a "distribution" jar without any "temporary files" that cljs generates. unfortunately, resulting modules are created inside the dir where temp files are thrown as well and things get a little bit messy. Having modules generated outside the :output-dir would make it easier to filter them out.

dnolen21:05:00

@michal right, we can probably make that work but it's super low priority since this is not a hard thing to work around

dnolen21:05:11

warning is an easy one just to avoid confusion

dnolen21:05:40

or if you're interested in working on that yourself, happy to take a patch that makes that work

colinkahn21:05:39

Is there a better way to read a clojurescript file as edn than using clojure.edn/read-string? The result i’m getting is just the ns form but it’s not including the rest. I’m assuming i’m not getting rest because I use some js interop w/ a node library but that’s just a guess.

ghadi21:05:38

read-string only returns the first form in a stream

ghadi21:05:48

you need to repeatedly read to consume the stream

👍 8
ghadi21:05:28

clojurescript files aren't EDN usually, btw @colinkahn -- you may want to use tools.reader or whatever clojurescript uses

ghadi21:05:57

(They can include metadata and feature expressions, which aren't in EDN)

colinkahn21:05:05

I see, thanks for the tip. I did try looking in the clojurescript repo briefly hoping to find how they were reading them in, but looking at tools.reader might be a good start

Alex Miller (Clojure team)21:05:29

cljs uses tools.reader

👍 4