I get this when I do a :simple or :advanced build, but would anyone have a guess? Cannot read property 'ReactCurrentOwner' of undefined

@iku000888 react v16? I think they removed that.

ah wait it work in :none? so then probably externs 😉

Suspected that 💥

app.js:193482 Uncaught TypeError: Cannot read property 'ReactCurrentOwner' of undefined
    at Object.r.116 (app.js:193482)
    at o (app.js:193479)
    at app.js:193479
    at Object.r.59.110 (app.js:193481)
    at o (app.js:193479)
    at app.js:193479
    at Object.r.30.10 (app.js:193480)
    at o (app.js:193479)
    at app.js:193479
    at Object.r.46.1 (app.js:193481)

So to elaborate

we have a gigantic bundle.js that is created with a npm script

which apparently :provides "cljsjs.react" "cljsjs.react.dom" "webpack.bundle"

But its still weird to me because I get the error with :simple optimization(Thought that would survive the renaming???)

hmm true, that should work. do you generate a different bundle for dev/release? ie use a minified build in :simple but not :none?

why do you do the bundle? didn’t you use shadow-cljs before?

Got a job with a project that was built with cljs compiler+figwheel up to now that needs to ship 😛

hehe ok 🙂

Given the amount of npm dancing, I agree shadow-cljs would be a good choice...

did you try the usual :pseudo-names debug to see where the ReactCurrentOwner is used?

maybe that can give a clue

Giving that a spin

wait .. nevermind

Really appreciate your time.

:simple

Was about to scream

yes simple

is the error above from a simple build?

as far as I can tell yes

at Object.r.116 (app.js:193482)
    at o (app.js:193479)

but same error with :advanced

that looks like errors on minified things

agree

:pseudo-names true also yields same result

:thinking_face:

yeah it looks like the issue is in the bundle. :simple should not have property names like that

maybe you generate the bundle with webpack -p instead of webpack -d for dev builds?

did you try the chrome debugger “Pause on exceptions” and debug that way?

Have not tried any of them! Will give a shot!

Could it be possible if

:foreign-libs [{:file "bundle.js"
                              :provides ["cljsjs.react" "cljsjs.react.dom"
                                         "webpack.bundle"]}]

then adding the react extern would do some magic?

since :simple has the issue I don’t think :externs are the cause

(I am interpreting this as react is included in the bundle)

Ah yes

you could try to including the bundle in a separate <script> tag and not telling the CLJS compiler about it

that would at least sort out if the error is in the bundle or your app.js

that is something suspicious

so now I have both the script tag and the :foreign-lib

refering to the same bundle

yeah just make the :foreign-lib refer to an empty file or so

Yeah, no luck.. Will try the other methodologies!

Thanks @thheller

Now I identified that (react and react-dom) come from the bundle but react-dom-server is not

Trying to exclude react-dom-server

maybe a stupid question, but… I just released my first cljs library to clojars, and included it in another project I am working on. However, in this project, I get Could Not Analyze errors when requiring the re-dnd.events namespace for instance. Are there special things I have to take into account before deploying to clojars? This is the lib in question: https://github.com/Kah0ona/re-dnd

ah doh, forgot to add src/cljs to source paths in leiningen

works now

Is there a limitation on using cljs core/async <! >! macros inside another macro? I stumbled upon this problem and reproduced it in this repo: https://github.com/fbielejec/gotry The macro simply wraps a body in a go-try-catch block and it gives me:

Error: >! used not in (go ...) block

@fbielejec shouldn't that be :refer-macros [gotry] (or (:require-macros ...))?

also, why is the gotry macro in the :cljs branch of a reader conditional?

@moxaj accroding to this it should work https://dev.clojure.org/jira/browse/CLJS-1507

but you're not doing that

it's a cljs-only macro for the simplicity of the example. Actually should probably be stripped of the reader conditional alltogether

clojurescript macros are implemented in clojure (unless you are using self-hosted)

it's a nodejs build

oh I see what you mean

well initially the macro was written with both targets in mind, hence the conditional

if by targets you mean clojure/clojurescript, reader conditionals wouldn't really have helped you there (assuming you are using regular clojurescript), because for both targets the clojure reader would have read the file

but the error indicates something else, i.e. that the outer macro is not expanded

having you tried my suggestions? :refer-macros and removed conditional

just trying 🙂

so the macro now becomes cljs.core.async.macros/go, and it works, thanks!

Has anyone else seen a cljs.tools.reader not found error when using a cljs compiler later than 1.9.671?

I currently avoid the problem by explicitely depending on tools.reader.

@iku000888 Don't know the details, but this is what I did: https://github.com/binaryage/env-config/commit/9be8a9fb533dc2c82978f2dffe0186ade1feb769

https://github.com/Microsoft/napajs

What are you guys using for shared data validation between client and server?

Anyone using clojure.spec? Or are there better libraries that help with form errors and things?

I see that Luminus uses struct. Is that still a solid go-to?

struct is good I hear 🙂

I like vlad too

prismatic/schema does portable data validation and it’s what my app uses since it’s a lot older than this new-fangled spec thing

struct does seem pretty nice. I've been using it a bit and I really like how it handles error strings; very easy to pop into a form.

I actually tried prismatic/schema out and found it really difficult to use, at least for form validation. I remember running into trouble with just simple (and () () ()) style predicates.

It had sort of its own DSL for doing predicates that I couldn't pierce

@noisesmith did you find a good way for schema to have good user-facing messages? That's where it always fell down for me, even the humanizer created things like "42 is not a java.lang.String"

@dominicm I pretty print the return value of s/check, which isn’t perfect but it usually helps me find the issue quickly

@noisesmith depends on what that message goes to I guess? 🙂

I’m just trying to update a few dependencies, but compilation blows up. Any ideas why I would get No reader function for tag Inf

one of the more recent cljs versions fixes this, it's needed if you update to the more recent clojure 1.9 builds

I’m using [org.clojure/clojure “1.9.0-beta2”] [org.clojure/clojurescript “1.9.946"]

@hkjels could be a tools.reader issue https://groups.google.com/forum/#!topic/clojure/dSrlFNdfIFE

Indeed! Thank you 😄