Fork me on GitHub
#clojurescript
<
2018-03-05
>
Garrett Hopper01:03:58

Is there a way I can use extern inference to prevent closure from munging the name of a node.js required module? (Instead of using externs)

souenzzo02:03:17

use strings ... [foo.bar :as bar] ["var/car.js" :as x]...

flowthing08:03:38

Is it bad practice to use a JavaScript object as a map key? For example, if I'd like to use a date as a map key, is it totally OK to use a goog.date.Date instance or is it better to serialize it into a string, for example?

noisesmith17:03:56

the thing to watch out for is that js objects are typically mutable (Date included) and if anyone mutates the key bad things happen

flowthing18:03:30

That's a good point. Shouldn't happen in this case, but definitely good to keep in mind — thanks!

Roman Liutikov08:03:48

@flowthing it’s fine, just keep in mind that you have to maintain a reference to such an object if you want to access the value in a map

flowthing08:03:19

Yeah, that's a good point. Thanks!

flowthing08:03:55

Although I guess in the case of goog.date.*, https://github.com/andrewmcveigh/cljs-time/blob/master/src/cljs_time/extend.cljs might also do the trick.

Naylyn09:03:22

Does anyone know offhand how figwheel launches the browser when it starts it's repl? I'm wondering if I can make it launch chrome by default so that I can use the cljs dev tools, while still having firefox as my default browser for everything else.

jrychter09:03:35

Ok, I'm now certain the :parallel-build option has race conditions. I suspected it for a while, as some of my builds were failing with bizarre messages, but now I caught it red-handed: if I have :parallel-build enabled, instead of catching a circular dependency the build will just hang indefinitely.

frankiesardo11:03:10

Hello there. Is there a way to turn off warnings for self-hosted clojurescript compilation?

frankiesardo11:03:49

cljs.js/eval automatically logs warnings but I want to disable them

frankiesardo11:03:05

Actually it's probably reported as error as the only way I have to stop that is (set! js/console.reportErrorsAsExceptions false)

jrychter12:03:46

@mfikes: indeed. I get this also with :optimizations :none. And it's just one of the issues I'm seeing with :parallel-build — the others are outright weird, such as errors in cljc compilation that disappear on the next build (I do clean things up between builds). I'm suspicious of this option.

mfikes12:03:27

@frankie Yes, you can bind cljs.analyzer/*cljs-warning-handlers* to a vector of whatever handlers you like or nil to turn them off altogether. (This is, for example, how Lumo and Planck provide markers pointing at the form causing the warning.) I suspect you can even squelch certain warnings but leave others.

mfikes12:03:40

@frankie In self-hosted, the analyzer is directly available to your self-hosted ClojureScript code. (Whereas in JVM-based ClojureScript, you need to adjust warnings at the Clojure level.)

frankiesardo12:03:25

@mfikes perfect that was exactly what I needed!

dnolen12:03:51

@jrychter it’s certainly possible though I think a lot of people use this option and we don’t get tons of reports

dnolen13:03:53

currently using it for the last 6 months on a project with at least a hundred source files, >20,000 LOC (not including deps) - and I haven’t had issues - but again - doesn’t mean much 🙂

mfikes13:03:46

@jrychter If you ever get it to hang again, be sure to use jstack or kill -3 on the compiler process so we can see where it is stuck (and perhaps drop the stack trace into CLJS-2055)

mfikes13:03:25

@jrychter Actually, I could be wrong about CLJS-2055; you may have no circular deps, and if you catch it hanging perhaps a new JIRA ticket is in order

jrychter14:03:15

Well, race conditions are racey and tricky. This is a large project (>30k LOC in 205 files). Problem is that if the compiler doesn't hang, I don't know how to get more information.

jrychter14:03:26

@mfikes: in my case I definitely did have circular deps. Once I removed the :parallel-build option I finally got the error message, removed the circular deps, and enabled the :parallel-build again, which didn't hang anymore.

mfikes14:03:53

Ahh, cool @jrychter. Well, a stack trace might help, as it is difficult to produce a minimal repro.

dpsutton14:03:31

that's bitten us as well. have to turn the parallel build option off to get the report of where the circularity is

dnolen14:03:01

yeah we need a circular dep check before we start - what we have for :none is insufficient

dnolen14:03:32

@jrychter you changed your report here though - did you or didn’t you get a error under :none?

dnolen14:03:42

@joelsanchez yeah, we need to do something like that

jrychter14:03:59

@dnolen: when using :parallel-build, the compiler hangs for me with :none. I've added this info to the JIRA issue in case it helps.

dnolen14:03:21

@jrychter sorry I got confused, I really meant didn’t you get an error when you turned it off, but anyhow, this should be petty easy to fix by reusing some stuff I wrote for module splitting, will be in the next release

mfikes15:03:15

General help request: Try the ClojureScript 1.10.126 pre-release with your project to see if it at least compiles without warnings. Better: Try a little smoke testing or run your unit tests.

miikka15:03:14

I get a zillion warnings about schema.core/MapEntry (both undeclared var and wrong number of args) in our app that uses prismatic/schema and also a runtime error "Maximum call stack size exceeded" with stack trace mentioning schema.core.MapEntry. Hmh!

miikka15:03:42

The undefined warnings come from lines of schema.core using defrecord and schema.core excludes cljs.core MapEntry. I bet that after CLJS-2482, defining your own type/record called MapEntry is broken.

mikerod16:03:22

Yeah, it looks like Schema has an issue. It came up for Clara rules yesterday

mikerod16:03:51

I don’t see any issue logged for Schema https://github.com/plumatic/schema/issues

mikerod16:03:03

I don’t understand the problem yet enough to log one. I think they may want a PR to fix it though. Not sure they’d fix it quickly otherwise (not sure on the level of support it has right now).

miikka16:03:49

Well, I'd say it's a bug in ClojureScript. MapEntry used to be perfectly fine name for a record.

mikerod16:03:04

Yeah, that was what I was thinking may be the case. I just dig through the error enough to know that was the issue.

mikerod16:03:31

There are actually quite a lot of recent cljs changes concerning map entries

miikka16:03:17

That link didn't go anywhere useful, but yeah, I noticed

mikerod16:03:49

Ah, thought I could share a query view. Anyways, just search for recent “mapentry” cljs Jiras

dnolen16:03:29

not a bug, we own core names - downstream projects must adjust

dnolen16:03:07

trying to coordinate around new core name is not something we intend to ever do

mikerod16:03:39

@dnolen Hmm, so shadowing of core vars and/or class names isn’t allowed (even with different namespaces)?

miikka16:03:44

@dnolen Schema does use :refer-clojure :exclude to exclude MapEntry, though! I'd expect this to work.

mikerod16:03:58

I find that surprising given refer exclusions and namespaces

dnolen16:03:48

no idea what the problem is, just saying we take core names when we see fit, we don’t coordinate here

miikka16:03:50

Yeah, that's reasonable, but also that's not the problem here

mikerod16:03:55

Core defining whatever name it wants sounds typical and expected. I think the surprise is an issue occurring with a :refer-clojure :exclude plus a defrecord by the name of MapEntry in a different namespace than cljs.core .

mikerod16:03:25

Obviously, we need more details to describe the problem precisely though.

miikka16:03:38

Anyway, for anyone interested, I don't have the time to write an issue right now, but this would fix the problem with Schema. https://github.com/miikka/clojurescript/commit/d1292babf870040a0470cd2916c71a2e492fd437 With that patch applied, our production 10k-line ClojureScript application builds without warnings and seems to work fine.

mikerod16:03:58

Ah I didn’t realize syntax quote wouldn’t do the qualifying automatically there.

miikka06:03:23

@mfikes, should I create a JIRA issue about this or what's the way to proceed?

mikerod15:03:33

@U1NDXLDUG Yeah, I was wondering about that. It sounds to me like something an issue would be logged for.

mikerod15:03:44

I was wanting to try to do a small reproduction case, but haven’t gotten around to it

miikka17:03:40

Well, for whatever it's worth, I posted it here: https://dev.clojure.org/jira/browse/CLJS-2621

mikerod17:03:34

Thanks for logging it

dnolen17:03:16

@U1NDXLDUG actually that’s what I needed, thanks, easy to fix

leontalbot15:03:28

I put together thoughts from @noisesmith @dchristianbell @jonpither and @mccraigmccraig on deciding between separating a clojure server/api codebase from a clojurescript client/ui or keeping them both together. https://gist.github.com/leontalbot/cc1ee6ddf57e840b335d700f38f02a72 Any more thoughts around the subject?

miikka15:03:21

Another vote for multiple modules in single repo from me. It really is the "best of the both worlds" solution: you can develop the frontend and the backend separately, but you don't have to face the friction of having multiple repos.

leontalbot18:03:25

@U1NDXLDUG Been discussing around… Would you mind describing a bit more the friction issues of having multiple repos? Thanks a lot!

Garrett Hopper17:03:59

Is there a way I can run a cljs repl in the background? I want to run a dev server with automatic reloading, but I don't want it taking over my current repl.

dnolen17:03:21

@ghopper the simplest way is component (or something like that) + socket REPL

deas18:03:03

Short question: Shouldn't the process shim (if we request it) always come first? First preload that is?

ag19:03:42

is there like a library that lets you query hiccup structure (vector) using selectors like syntax? basically "jquery for hiccup"?

noisesmith19:03:45

@ag yes, hickory and enlive can both do this

ag19:03:14

seems hickory is what I need. basically I'm trying to test component functions. We've been using Enzyme, but realized that you don't have to actually render things in the DOM and then confirm that it indeed produces right html. You can simply invoke the component function and analyze the hiccup it produces

souenzzo19:03:01

@ag take a look at #specter It's really easy to deal with huge/complex structures

ag19:03:50

but no, I just need something like jquery but for hiccup

ag20:03:26

dang it... hickory selectors only work for html parsed as-hickory. I need something hiccup native

ag20:03:12

I guess I'm gonna try enlive

ag20:03:35

wow... To much of my surprise I can't find anything very simple that lets you work with hiccup syntax and do something like:

(find 
 [:div 
   [:div.child
     [:input {:type :checkbox}]]]
 "input[type='checkbox']")

ag20:03:27

maybe this? [hiccup-find "1.0.0"]

ag20:03:32

¯\(ツ)

noisesmith19:03:12

enlive doesn't use hiccup by default, but it's the one I've used the most, it's good

noisesmith19:03:23

(I used it for web scraping)

dnolen19:03:50

@deas there’s no such guarantee no

deas19:03:29

@dnolen Asking because I am seeing an issue caused by custom :preload relying on process which in turn comes into play too late.

dnolen19:03:53

like I said doing that is not really supported

deas19:03:27

@dnolen Got it. Any reason for not allowing user to specify order of preloads or at least make process come first when using :process-shim?

dnolen19:03:11

order of preloads is respected far as I know, but dependencies between is not

dnolen19:03:47

there’s really not a good way to do what you want, just supply :preloads yourself manually

deas19:03:29

Other than that, it seems 1.10.126 miscompiles react-dom (16) from node modules for me. (DCE issue). 1.9.946 does not expose this behaviour and does it correctly - at least wrt react-dom/index.js. Should I bother coming up with a bare bones repro?

dnolen19:03:44

@deas first you have to determine we can do anything about that

dnolen19:03:54

if it’s truly DCE then it’s not our problem

ag20:03:35

wow... To much of my surprise I can't find anything very simple that lets you work with hiccup syntax and do something like:

(find 
 [:div 
   [:div.child
     [:input {:type :checkbox}]]]
 "input[type='checkbox']")

dnolen20:03:59

maybe, or for us as a community to look at the problem first 🙂

dnolen20:03:26

as I said in the very beginning :npm-deps ain’t going to fix itself - it’s going to take lot of work from everyone