So, when and why do you sometimes need to use strings for require?

generally if they have characters that aren't valid symbol

e.g. scoped npm packages are of the form @corp/my-lib

i think @bhauman made a version of that with https://github.com/bhauman/cljs-test-display

I noticed it isn't documented it seems

Neither on the namespace guide, or on the doc-string of require and ns

Does anyone use a testing library for testing react components? Which one do you use and why?

I like react-testing-library

is there a way to find the exact line number where an error occured in my cljs file? My stack trace doesn't show the line so it's harder to debug:

Error mounting card {ns: myapp.workspaces.cards-test", name: "cart-not-shown-initially-test", str: "myapp.workspaces.cards-test/cart-not-shown-initially-test", _hash: 69565119, _meta: null, …}cljs$lang$protocol_mask$partition0$: 2154168321cljs$lang$protocol_mask$partition1$: 4096name: "cart-not-shown-initially-test"ns: "myapp.workspaces.cards-test"str: "vendo.workspaces.cards-test/cart-not-shown-initially-test"_hash: 69565119_meta: null__proto__: Objectapply: ƒ (self__,args66157)call: ƒ (unused__32982__auto__)cljs$core$IComparable$: {}cljs$core$IComparable$_compare$arity$2: ƒ (x,y)cljs$core$IEquiv$_equiv$arity$2: ƒ (_,other)cljs$core$IFn$_invoke$arity$1: ƒ (coll)cljs$core$IFn$_invoke$arity$2: ƒ (coll,not_found)cljs$core$IHash$_hash$arity$1: ƒ (sym)cljs$core$IMeta$_meta$arity$1: ƒ (_)cljs$core$INamed$_name$arity$1: ƒ (_)cljs$core$INamed$_namespace$arity$1: ƒ (_)cljs$core$IPrintWithWriter$_pr_writer$arity$3: ƒ (o,writer,_)cljs$core$IWithMeta$_with_meta$arity$2: ƒ (_,new_meta)cljs$spec$alpha$Specize$: {}cljs$spec$alpha$Specize$specize_STAR_$arity$1: ƒ (s)cljs$spec$alpha$Specize$specize_STAR_$arity$2: ƒ (s,_)equiv: ƒ (other)garden$selectors$ICSSSelector$: {}garden$selectors$ICSSSelector$css_selector$arity$1: ƒ (this$)toString: ƒ ()constructor: ƒ (ns,name,str,_hash,_meta)__proto__: Object TypeError: Cannot read property 'cljs$core$IFn$_invoke$arity$1' of null
    at Object.nubank$workspaces$ui$render_card [as render_card] (ui.cljs:71)
    at nubank$workspaces$ui$WorkspaceSoloCard.eval [as componentDidMount] (ui.cljs:226)
    at commitAllLifeCycles (react-dom.development.js:17335)
    at HTMLUnknownElement.callCallback (react-dom.development.js:150)
    at Object.invokeGuardedCallbackImpl (react-dom.development.js:200)
    at invokeGuardedCallback (react-dom.development.js:257)
    at commitRoot (react-dom.development.js:18949)
    at eval (react-dom.development.js:20419)
    at Object.exports.unstable_runWithPriority (scheduler.development.js:256)
    at completeRoot (react-dom.development.js:20418)

@lilactown I mount the component like so, using react-testing-library

(defn mount-cart-component! []
  (render ([:div {:id "cart"}]))
  )

(deftest my-test
    (mount-cart-component!)
    ;; ...
)

When I do it this way, the error disappears:

(defn mount-cart-component! []
  (render (:div {:id "cart"} "Cart"))
  )

(.getByText screen "Cart")

TestingLibraryElementError: Unable to find an element with the text: Cart.

Does anyone know if the new webpack support would offer anything over / be worth switching to from: deps.edn, figwheel-main w/ an existing webpack serving as input to the CLJS build?

Basically this: https://github.com/bhauman/figwheel-main/blob/master/docs/docs/npm.md

Looks like maybe it would just save having to manually type the :global-exports

Is that right?

As you say fairly similar to preparing npm deps as a webpack and then consuming them.

But it gives you js tooling reach too. I think you can get things like storybook to consume your views. (Untested)

Others might have more compelling examples

@olivergeorge wouldn’t that “js tooling reach” be counteracted by a “cljs tooling shrinkage”? Or would it really be a “best of both worlds” scenario?

I’m hoping it’s a “cherry pick the best” type scenario!

does anyone know how to use the react-testing-library in clojurescript?

my render function from this library doesn't load the rendered component on the dom.

No promises but perhaps this helps. https://github.com/mdxprograms/d4rkst4r-v2/blob/d7a3ac070f205aa042236a8a77ee3d59f431f9ba/src/app/hello_cards.cljs

I searched github for Clojure code including “testing library cljs react”

There might be better examples out there.

@johanatan the problem w/ the old way is that it was "backwards" so it created more configuration - to be honest it wasn't really that hard but it was a stumbling block. In the new way where you pass on to a JS build tool you don't need to bother with configuration at all. So fewer opportunities for user error

been trying out the latest cljs with npm stuff, good stuff... wondering how the tree shaking works, if I require a bunch of node modules in my ns, but the functions that use them are ultimately unused, will they be left out of advanced build?

@johanatan re "tool-shrinking", there's actually not that many build tools in the ClojureScript system - nothing like JS. Part of the problem is that some fundamental things need to be solved in ClojureScript first like externs inference. There are exceptions like shadow-cljs because it reimplemented stuff or fixed stuff out of tree - but that's not helping anything but shadow-cljs.

@tatut hopefully the initial docs were pretty clear on this, if you're passing onto bundler none of the node_modules stuff is going through Closure

it's trivial to take a bundle target project and convert it to pass everything through Closure but not useful because it's not going generate stuff that will work.

note not working has nothing to do w/ Closure or ClojureScript

the JavaScript stuff simply isn't compatible

(with advanced compilation)

(ns foo (:require ["some/npm/Stuff" :as bar])) (defn baz [] (bar/dothing)))

I'd just be repeating myself

ok, I'll try it.. still don't understand fully, sorry

nothing that you use from node_modules will ever be looked at by Closure

Closure doesn't know what you're calling, it will never see the thing called, so it can't possibly eliminate it

we could handle the trivial case you demonstrated but it's really meaningless

that's not how Closure DCE works

it looks at everything

(as long as it's something you've inputted to the compiler, not true for node_modules and the bundle target)

ok, thanks for explaining

if I understand correctly, there's possible implications for cljs library authors that rely on npm stuff on how to structure into namespaces

The guide https://clojurescript.org/guides/webpack does not work under Windows (PowerShell). I get this,

;; clj -m cljs.main -co build.edn -O advanced -v -c -s
Applying optimizations :advanced to 42 sources
Execution error (InvalidPathException) at sun.nio.fs.WindowsPathParser/normalize (WindowsPathParser.java:182).
Illegal char <:> at index 2: /C:/Users/hiadhy/Code/<snipped>

@dnolen if you're around, we spoke the other day about inference warnings and protocols - I've tried yesterday's release of CLJS and still unfortunately getting some warnings - is there something missing in the repro case on https://github.com/dazld/cljs-protocol-inference-warning ...?

Hi! I understand that CLJS's resolvetakes only a static symbol because of advanced compilation. However, I need to resolve a symbol dynamically but at compile time, I cannot manage to find how to do that

@adam678 it's not possible

https://ask.clojure.org/index.php/8976/offer-resolving-facility-friendlier-towards-macro-authors The ones here eg cljs.analyzer/resolve-var give you the known information about a symbol, which can be dynamic at compile time It just can't be dynamic at runtime

Hi, beginners question, but can't seem to find a straightforward solution for it: I'm using cljs-http to send a request to an api, but don't understand how to get the returned value out of the async channel. Within a go block, I can call <! and do things with the resulting response inside the go block, but I'd like to have my function return the response, rather than being forced to use it inside this go block. How do I get the go block to return the response, rather than the channel itself? I assume I'm tackling this from the wrong angle?

@adam678 it's not about good or bad, it's actually not possible

because of advanced compilation

does anyone use use-fixtures for testing in clojurescript? How do you get it to work?

I have the following use-fixtures defined in my test file:

(use-fixtures :each {:before (fn []
                               (prn "using fixtures")
                               ) :after #()})

Hi what do you guys use for JWT? https://github.com/funcool/buddy seems to be very old and not taken care of

i've used that at a previous job. i don't believe jwt's have changed in the meantime. it served my purposes fine and is maintained by some security conscious people as far as i know. but those are jvm based i believe so not suitable for cljs

wasn't there a ticket to have cljs.repl/{doc,dir} work on GCL? so you could call dir on goog.events and similar? I looked in jira and not finding it and wonder if i'm misremembering? and nevermind it works. i thought i had checked it recently.

🙂

that is incredibly helpful. thanks @dnolen!

Can someone help me with externs? I wrote this code to improve on the datatables recipe: https://pastebin.com/PxPinWKw. After setting infer-externs & `warn-on-infer` I get these warnings: https://pastebin.com/nwdFJSZQ. My understanding is that I'm supposed to provide type hints, but I don't know how to determine the types I'm supposed to hint eg "what is .destroy a member function of?" Additionally, I recompiled the namespace with *warn-on-infer* and these warnings went away. Does that mean an externs file has already been generated? Where would it be located?

@dpsutton I think with the new global require proposal this will be way cooler

docs and validation for all standard HTML apis

i've overhauled inf-clojure so that the experience is extremely nice with just the raw cljs.main and i'm loving it. so thanks for prodding me on that. and i'm looking forward to it. thanks for all your work!

stuff like this https://github.com/google/closure-compiler/blob/master/externs/browser/w3c_dom3.js#L102-L110

tons of stuff in the standard set of externs

@dpsutton glad to hear inf-clojure + cljs.main works well! that was my preferred Emacs setup

it would parse that info to emit warnings similar to WARNING: cljs.core/+, all arguments must be numbers, got [string number] instead at line 1 <cljs repl> ?

(from your "validation" suggestion)

not type based stuff, though I've had thoughts floating around but nothing actionable

stuff like doc would work for HTML apis

(doc window) (doc console)

but argument count would be validated just like for real GCL libs

that sounds quite nice. i'm really digging the thoughful run-time documenting aspects of clojure. gonna have to go vote on that javadoc ticket for clojure 1.11

a bigger project to think about is seeing if we could reconcile fns specs w/ the interop barrier

instead of polluting our code w/ types we could just use the fnspecs and compare against the externs

this would get you at least Common Lisp level basic checking which is still reasonable - could be REPL friendly too

anyways - this not something I'm planning on working on in the very near future - but it's been in the back of my mind for a long time

we used to use Closure type checking, but I could not make it do what I wanted and it was not usable during REPL dev, only advanced

the type inference is getting good enough where this new line could be reasonably explored

REPL friendly type assistance would be pretty cool - not so common a feature in languages

not a huge fan of TypeScript, but I understand that having some type checking is flat yes/no for some people assessing technologies

I think having the option to check specs against inferred types and externs would draw those kinds of users in

by fnspecs do you mean cljs.spec fdefs, or are fnspecs something I haven't learned about yet?

yes I mean cljs.spec

Is there anything like (type thing) in cljs which gives me the information needed to include type hints? type works in clojure for this purpose but apparently not clojurescript.

To try this a third way, the externs guide (https://clojurescript.org/guides/externs) teaches you to type hint in order to produce externs.  @dnolen goes through an example where he type hints `wrap-baz` with `^js/Foo.Bar`, but doesn't show me how he determined that `^js/Foo.Bar` is the type hint which was needed.  How did he do that?

there's not a generic way to get the type in JS

type just returns the constructor

for externs it's really not needed - you can just ^js and be done w/ it

Thank you!!! I'll give ^js a try and see if that removes the inference warnings

has anyone used jest with clojurescript? How did you install it? After I install it using npm install jest and add "test":"jest" in package.json, I expect keywords like "expect" to work:

(.toBeInTheDocument (expect (.getByText screen "Some Component")))

@dnolen I added ^js type hints to three of the member accesses and I am still seeing inference warnings. https://pastebin.com/A7cbdjGB

try adding hints to the actual expression, e.g.:

(.-refs ^js component)

if that does fix it, I am not sure if that's an error with the inference or not

Um, ew.

(defn home-did-mount [^js this]
  (.DataTable ^js/$
   (js/$ ^js (.-main ^js (.-refs ^js this)))
   (clj->js
    {:columns columns
     :data data
     :responsive true})))

It does seem to get rid of the inference warnings around this function. I had to use ^js/$ for that second one, though.

do you have extern inference on?

I have :infer-externs on in my cljsbuild config, but only for building the uberjar.

@doubleagent you should only need to do it once for this, are you using 1.10.741?

@dnolen I'm on 1.10.597

there some externs issues with 597, but anyways, what warnings do you get with only hinting the fn arg on 597

Figwheel: Compile Warning - Adding extern to Object for property refs due to ambiguous expression (. this -refs) in file src/cljs/bigboard/core.cljs at line 381, column 4
Figwheel: Compile Warning - Adding extern to Object for property main due to ambiguous expression (. (.-refs this) -main) in file src/cljs/bigboard/core.cljs at line 381, column 4
Figwheel: Compile Warning - Adding extern to Object for property DataTable due to ambiguous expression (. (-> this .-refs .-main js/$) DataTable (clj->js {:columns columns, :data data, :responsive true})) in file src/cljs/bigboard/core.cljs at line 380, column 3

@dnolen ^

right it's just complaining about object so give it the type

@doubleagent see #figwheel-main

@nathan.probst this is not a figwheel issue it's ok

Ah. Cool.

@doubleagent what is the type of that argument, you must know since you're getting it from somewhere

I think it's a React.Component, but honestly I don't know because reagent hides a lot of that stuff from me.

I'll try that.

^js/React.Component

@dnolen that reduces the warnings to one.

Figwheel: Compile Warning - Adding extern to Object for property DataTable due to ambiguous expression (. (-> this .-refs .-main js/$) DataTable (clj->js {:columns columns, :data data, :responsive true})) in file src/cljs/bigboard/core.cljs at line 380, column 3

Using :target :bundle and using the dependency "chart.js" , which has a non-valid clojure name and returns its constructor, what would be the sensible way to deal with that? I see that it’s possible to use an alias in package.json so you can call it something like "chartjs". But how about usage? You can’t run the alias as a constructor:

(require [chartjs])
(chartjs. params)

@ingesol we do support invokeable ns, but we may need to expand that

if it doesn't work file an issue in JIRA with error information etc.

@doubleagent same problem, what is the type of the thing with DataTable method?

Beats me. It's whatever jquery's $ function returns when passed an HTMLTableElement Do I need to go read the jquery source code in order to figure it out?

I can't help you figure that out, you can also just ignore the warning

but it sounds like you know the answer anyway

HTMLTableElement will probably work fine

jquery documentation says it's a collection, but maybe it collapses the colletion when there is only one matching element.

I'll try ^js/HTMLTableElement

That didn't work.

what didn't work? paste the expression

(defn home-did-mount
  [^js/React.Component this]
  (reset! x this)
  (.DataTable
   ^js/HTMLTableElement
   (-> this .-refs .-main js/$)
   (clj->js
    {:columns columns
     :data data
     :responsive true})))
Figwheel: Compile Warning - Adding extern to Object for property DataTable due to ambiguous expression (. (-> this .-refs .-main js/$) DataTable (clj->js {:columns columns, :data data, :responsive true})) in file /c:/Users/doubl/OneDrive/Documents/GitHub/bigboard/src/cljs/bigboard/core.cljs at line 384, column 3

@doubleagent ok this one I think is fixed by 1.10.741

but Figwheel is not yet compatible - so you should just ignore

nothing bad is going to happen

@dnolen my understanding was that it would break under advanced compilation

that's not correct

Ah, okay. My mistake.

the warning just says it doesn't know what the type is so it's creating an extern on Object

Alright, thanks

@ingesol I looked at the analyzer - it seems like it should work - but you didn't really give enough information about what didn't work for you

also you don't need to bother with the alias in package.json, (:require ["chart.js" :as chart]) should work

@dnolen oh, I just assumed that those things were specific to shadow-cljs. It probably works then, sorry for the confusion

@ingesol the semantics of shadow are subtly different and should never be relied upon in code you intend to publish (as a library)

in shadow-cljs I believe string requires means it's a JS module, not true for ClojureScript

ClojureScript just generally allows namespaces to specified as strings

that's pretty old feature too - almost three years now

@dnolen I learnt something today then :) only saw examples in shadow before

we had to solve that problem way back when we did all the work to push everything through Closure

lots of package names in node_modules aren't valid symbols

and all the various usage patterns etc.

those things were done independently of the bundler stuff

in the end while the bundler stuff appears to be big news, it was really minor changes to tie together the work of the past 5 years

I guess in theory, if your npm deps can go through Closure, that might still be beneficial to go that route for those and get the benefit of dead code elimination

@didibus that's the long game

I take it (with-open ...) doesn't work with cljs?

I'm following the webpack guide, but noticed that with -r and -v option the repl doesn't appear in the console until I press enter. the initial output for the repl is injected somewhere in between the output

More less expected with -v output I’ll probably remove that, it just makes it easier to know that some is happening

Something I mean