Fork me on GitHub
#shadow-cljs
<
2020-07-27
>
Karol Wójcik07:07:28

Trying to test react components using "@testing-library/react". After compiling and running with karma I'm receiving following errors: Question: How to test React components in cljs?

Chris McCormick07:07:10

is there a way to suppress building the manifest.edn completely?

thheller08:07:14

@karol.wojcik I don't know anything about testing react components but the above error you can fix by setting :compiler-options {:output-feature-set :es7} or maybe :es6 or :es8. depends on what the lib uses and what karma supports

Karol Wójcik10:07:55

Using the latest shadow-cljs. Anyway applying :es8 fixed the issue 🙂 Thanks!

thheller08:07:35

is this with the latest shadow-cljs? I though I fixed all the $jscomp issues. if not maybe try upgrading.

thheller08:07:54

@chris358 no but I can add an option for that. open an issue if you want, otherwise I'll forget 😉

Chris McCormick08:07:12

it is really not important. i can just add the file to .gitignore.

thheller08:07:34

your entire :output-dir should be gitignored 😛

Chris McCormick08:07:36

it is created during release as well

Chris McCormick08:07:56

my release artifact is checked in on a branch as i use git push to deploy.

thheller08:07:04

yikes. doesn't that make your entire git repo disturbingly large after a while?

thheller08:07:51

well I guess github does it for github pages too so can't be that bad 😛

Chris McCormick08:07:28

my git repos are not excessively large. git's diffs are very efficient and builds are not that frequent. sometimes i build into an entirely separate repository (e.g. project is the source and project/build is a separate repo containing the artifact). yes, it's the same strategy as github pages and some other static page providers.

thheller08:07:56

hmm don't git diffs fail completely for :advanced builds? didn't try in a while but it was bad?

Chris McCormick08:07:07

yes git diffs of checked in artifacts would be very ugly. i don't do this.

schaueho12:07:34

I'm running into a dependency issue and could use a hand to figure out what's going on. Here's the error on compiling: The required JS dependency "path" is not available, it was required by "node_modules/node-gyp-build/index.js".

schaueho12:07:15

I did an npm install --save path already and the path library is available in node_modules. Any help appreciated.

thheller12:07:30

@schaueho looks like you are trying to use a package that isn't supported in the browser. might be node only. as for the path package you need to have shadow-cljs installed in your project. that provides the required polyfills.

thheller12:07:22

the node-gyp stuff is for building native packages so very likely it won't work in the browser

Pavel Klavík12:07:43

Hi, I am getting the following error when trying to print my Re-frame app-db using Shadow-cljs REPL:

Pavel Klavík12:07:43

Exception in thread "XNIO-1 I/O-1" java.lang.RuntimeException: com.fasterxml.jackson.core.JsonParseException: Invalid UTF-8 middle byte 0x70
 at [Source: java.io.ByteArrayInputStream@4922222; line: 1, column: 2828]
        at com.cognitect.transit.impl.ReaderFactory$ReaderImpl.read(ReaderFactory.java:114)
        at cognitect.transit$read.invokeStatic(transit.clj:319)
        at cognitect.transit$read.invoke(transit.clj:315)
        at shadow.cljs.devtools.server.common$fn__14820$fn__14821.invoke(common.clj:47)
        at clojure.core$map$fn__5862$fn__5863.invoke(core.clj:2742)
        at clojure.core.async.impl.channels$chan$fn__872.invoke(channels.clj:300)
        at clojure.core.async.impl.channels.ManyToManyChannel.put_BANG_(channels.clj:83)
        at clojure.core.async$put_BANG_.invokeStatic(async.clj:199)
        at clojure.core.async$put_BANG_.invoke(async.clj:187)
        at shadow.undertow$fn$reify__16147$handler_fn__16148.invoke(undertow.clj:314)
        at shadow.undertow.WsTextReceiver.onFullTextMessage(WsTextReceiver.java:20)
        at io.undertow.websockets.core.AbstractReceiveListener$2.complete(AbstractReceiveListener.java:156)
        at io.undertow.websockets.core.AbstractReceiveListener$2.complete(AbstractReceiveListener.java:152)
        at io.undertow.websockets.core.BufferedTextMessage.read(BufferedTextMessage.java:105)
        at io.undertow.websockets.core.AbstractReceiveListener.readBufferedText(AbstractReceiveListener.java:152)
        at io.undertow.websockets.core.AbstractReceiveListener.bufferFullMessage(AbstractReceiveListener.java:90)
        at io.undertow.websockets.core.AbstractReceiveListener.onText(AbstractReceiveListener.java:70)
        at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:44)
        at io.undertow.websockets.core.AbstractReceiveListener.handleEvent(AbstractReceiveListener.java:33)
        at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
        at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:952)
        at io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:932)
        at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
        at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
        at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
        at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
Caused by: com.fasterxml.jackson.core.JsonParseException: Invalid UTF-8 middle byte 0x70
 at [Source: java.io.ByteArrayInputStream@4922222; line: 1, column: 2828]
        at com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:1702)
        at com.fasterxml.jackson.core.base.ParserMinimalBase._reportError(ParserMinimalBase.java:558)
        at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._reportInvalidOther(UTF8StreamJsonParser.java:3550)
        at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._reportInvalidOther(UTF8StreamJsonParser.java:3557)
        at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._decodeUtf8_3fast(UTF8StreamJsonParser.java:3359)
        at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishString2(UTF8StreamJsonParser.java:2521)
        at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishAndReturnString(UTF8StreamJsonParser.java:2469)
        at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.getText(UTF8StreamJsonParser.java:315)
        at com.cognitect.transit.impl.JsonParser.parseVal(JsonParser.java:60)
        at com.cognitect.transit.impl.JsonParser.parseMap(JsonParser.java:112)
        at com.cognitect.transit.impl.JsonParser.parseArray(JsonParser.java:128)
        at com.cognitect.transit.impl.JsonParser.parseVal(JsonParser.java:56)
        at com.cognitect.transit.impl.JsonParser.parse(JsonParser.java:46)
        at com.cognitect.transit.impl.ReaderFactory$ReaderImpl.read(ReaderFactory.java:112)
        ... 25 more

Pavel Klavík12:07:43

Any idea what could be causing this? The app works in the browser fine.

schaueho12:07:10

Yeah, I'm trying to use sodium-plus, which in turn tries to use sodium-native, which is using the browser NaCL stuff.

thheller12:07:30

@pavel.klavik not a clue but try (tap> app-state) and the UI 🙂

Pavel Klavík13:07:38

Ok, so the data gets printed in UI fine. How do you control it to explore the map?

thheller13:07:18

just click things

Pavel Klavík13:07:16

ya, makes sense, it got broken somehow because Shadow got stuck, working now

Pavel Klavík13:07:55

and when clicking on dashboard, I just get

Pavel Klavík13:07:02

so the problem is probably somewhere there

thheller13:07:52

interesting. would be curious to see what you have in there causing this 😛

thheller13:07:44

you can click the "EDN" button on the bottom. maybe that works? or pprint?

thheller13:07:07

but the UI also uses transit so makes sense it also fails

thheller13:07:06

hmm also probably crashes

thheller13:07:22

any visible exceptions? browser console, process output?

Pavel Klavík13:07:45

not anything, I can check what data are send from the server

thheller13:07:19

I have nothing in the UI to handle failures since I had nothing that caused a failure before 😛

thheller13:07:35

would be rather interesting what this is

thheller13:07:33

maybe a string with some weird unicode or so that isn't escaped properly and confuses the JSON parser

Pavel Klavík13:07:02

should be, there are no strange characters in names, etc., so not sure

Pavel Klavík13:07:11

any idea how to do debugging of this?

thheller13:07:36

this is a browser app right?

thheller13:07:05

try (tap> (pr-str app-state)) in the REPL

thheller14:07:22

no clue how to trim it down

thheller14:07:39

can't really think of anything that would make this fail

Pavel Klavík14:07:19

and I am getting the same error from Shadow-cljs

thheller14:07:44

yeah ok then there is something in the output that can't transfered via transit

thheller14:07:44

all google searches suggest its a bad utf-8 string, just gotta find it 😛

thheller14:07:41

maybe try trimming it down as much as possible and just use (js/console.log (pr-str (:dashboard app-state))) or so

Pavel Klavík14:07:15

makes sense, will try this out

Pavel Klavík14:07:43

I could probably erase everything since it happens in my testing data, but I am curious what is going on

thheller14:07:53

me too 🙂

Pavel Klavík14:07:18

also I was trying to tap another state where dashboard was not loaded (and which fails as well)

Pavel Klavík14:07:44

and while exploring, I am getting stuck on clicking some top keys and getting this error in console: WARNING] :shadow.remote.relay.local/client-sent-invalid-msg - {:client-id 52, :msg {:op :obj-request, :to nil, :oid nil, :request-op :nav, :idx 2, :call-id 21}}

Pavel Klavík14:07:33

it happens when clicking on :dashboard

Pavel Klavík14:07:48

Ok, so it seems to be breaking on something which looks like this:

[:strong {} "And maybe not this. And maybe not this. "
                         [:span {} " And maybe not this. " [:strong 
{} "And maybe not this. And maybe not this.  "]]]

Pavel Klavík14:07:00

super weird, nothing seems strange there

Pavel Klavík14:07:49

no idea what is going on, I will probably just reset my development data and hopefully I won't see this error again, super weird

Mikael Andersson18:07:00

I've seen issues where editors under some circumstances get an invalid byte sequence in the source code, which then also is invisible in the editor. It's not super common, but if the issue persists, try running code/data through cat -v, od -t x1c , hexdump, or whatever gets you byte values without any character set conversion. Cat -v might be multibyte aware on some platforms, so the other alternatives are safer if you are unsure.

schaueho12:07:31

And you're right, I'm running directly into the next issue.

schaueho13:07:20

Just FYI, following this recipe and assigning sodium-plus to the window object allowed me to use it then. Thanks again for the nudge in the right direction!

thheller12:07:31

looks like you can't use it directly from npm

thheller12:07:40

you can also set :js-options {:resolve {"sodium-native" false}} that will make it ignore that package

thheller12:07:51

no clue if thats enough though. may break in other ways.

schaueho12:07:14

will try that, thanks a ton for the input!

ShaneLester17:07:31

I was reading somewhere that turning aot-cache to false might fix an issue I'm having when I'm targeting a node module as my output. On the https://shadow-cljs.github.io/docs/UsersGuide.html#compiler-options it says that aot-cache is "unsupported or non-applicable"-- does this mean that it is false by default? or is it always true?

thheller17:07:43

what issue do you have? aot-cache is not a thing in shadow-cljs. it has a different caching mechanism.

ShaneLester17:07:39

Ahh ok. Was a bit of a longshot. Essentially, I'm using a material-ui datepicker which requires moment and some moment utils, and I'm using cljsjs/moment to get some of that to work. It works fine locally / deployed in our normal process, but when we try to export our project as a node module with shadow, it can no longer find the default MomentUtils it needs from dateio/moment. I was googling and got spit out to https://figwheel.org/docs/npm.html "Problems with cached compiled assets" section, and obviously this is a different product but what it was describing in that section seemed pretty familiar to what I was running into. I think I may have been mistaken / misunderstood what that aot cache actually does though

thheller17:07:28

this goes a lot quicker if you provide more details about the actual problem. not what you searched to fix it.

thheller17:07:37

> it can no longer find the default MomentUtils it needs from dateio/moment.

thheller17:07:40

what does that mean?

thheller17:07:05

cljsjs/moment is also a problem in itself so that may be your issue. shadow-cljs does not support CLJSJS.

ShaneLester17:07:06

I'll refine what my actual issue is and come back, just wanted to provide context to why i asked the question. Part of my current problem is I haven't exactly identied the problem yet

thheller17:07:14

you should just use the npm packages directly instead

ShaneLester17:07:15

ah ok. I will try to get rid of that overall

ShaneLester17:07:40

thanks for the response, and sorry for the lack of good details

thheller17:07:08

just (:require ["moment" :as mom]) and then (mom/whatever ...) should be fine. dont use cljsjs.moment and js/moment

neilyio20:07:32

Following the instructions https://shadow-cljs.github.io/docs/UsersGuide.html#_repl_3 for setting the :devtools key on my build, but it doesn't seem to be taking effect when I restart the server. I'm expecting the REPL to start in the namespace app.main, according to my shadow-cljs.edn config below, but it still starts in cljs.user. repl-pprint doesn't seem to be having any effect either.

{:source-paths
 ["src"]

 :dependencies
 [[fullcontact/full.async "1.1.0"]]

 :builds
 {:main
  {:target :node-script
   :main app.main/main
   :output-to "public/main.js"
   :devtools {:repl-init-ns app.main
              :repl-pprint true}}}}