Fork me on GitHub
#figwheel-main
<
2018-09-04
>
onetom04:09:44

i was asking about some visualization of how figwheel/repls work. i just noticed amongst my tweets a retweet of this: https://www.reddit.com/r/Clojure/comments/6kht1e/diagramming_the_flow_of_figwheel/ (the link in the article is broken. have to change http://planttext.com to http://plantuml.com in the diagram's url)

😀 4
bhauman12:09:43

yes I should probably take that diagram as inspiration for creating a more accurate one for figwheel-main

FluffyPuppy06:09:50

It's a tetris tutorial using figwheel and reagent

pesterhazy08:09:44

@bhauman can confirm that ns auto-detection works now

pesterhazy08:09:26

also the target directory fix 💥

pesterhazy09:09:44

I'd like to be able to use the same cljs-spa.test-runner ns for cljs-test-display and from the CLI

pesterhazy09:09:45

Am I right in assuming that to trigger something in the Extra Main page you need to run code at NS init time?

pesterhazy09:09:45

Oh, and I tried :auto-testing - it works great! Is it planned to support auto-testing from the command line as well?

bhauman12:09:11

@pesterhazy thanks for confirming all of this, I’m going to look at out your PR sometime today.

bhauman12:09:51

extra-mains can use the on-load hook metadata as well

bhauman12:09:19

but because of the nature of extra-mains its probably better to just put it at the top level

bhauman12:09:30

I should add this to the docs

bhauman12:09:00

I’m glad you like auto-testing, I think it should obviate the need for a test-runner that does both.

bhauman12:09:20

It hadn’t occurred to me to do autotesting from the command line. You could just change the :open-url to the testing endpoint and that would do it.

dpsutton12:09:31

and the test runner is a source of merge conflicts all the time. really glad to see this focus

bhauman12:09:14

so glad to finally be getting to it

bhauman12:09:47

hmmm I’m going to have to put more thought into what it would take to have auto testing from the command line

bhauman12:09:56

but clearly its possible

👍 4
pesterhazy13:09:42

I'm debugging the weirdest problem with reagent/react with figwheel main

pesterhazy13:09:37

I get a runtime exception, Cannot read property 'render' of undefined

pesterhazy13:09:14

but react-dom is mapped to window.ReactDOM in foreign-libs

pesterhazy13:09:54

and window.ReactDOM.render most definitely exists (as seen from the devtools console)

pesterhazy13:09:43

I'm using a webpack bundle to provide react-dom

pesterhazy13:09:21

The compiled js looks like this

reagent.dom.node$module$react_dom.render.call()

bhauman13:09:23

I know what this is

pesterhazy14:09:43

@bhauman I'm on the edge of my seat

pesterhazy14:09:58

I thought it would be missing :exclusions

pesterhazy14:09:16

but clojure -Stree is clean (no mention of cljsjs)

bhauman14:09:21

whats happening is that the goog.require('react-dom') is async right before var reagent.dom.node$module$react_dom.render = js/ReactDOM

bhauman14:09:44

if you look at the code in the file compiled file

bhauman14:09:32

the question is when is this happening to you?

pesterhazy14:09:26

the preamble looks like this

// Compiled by ClojureScript 1.10.238 {}
goog.provide('reagent.dom');
goog.require('cljs.core');
goog.require('react_dom');
goog.require('reagent.impl.util');
goog.require('reagent.impl.template');
goog.require('reagent.impl.batching');
goog.require('reagent.ratom');
goog.require('reagent.debug');
goog.require('reagent.interop');
reagent.dom.global$module$react_dom = goog.global.ReactDOM;

bhauman14:09:02

so if goog.global.ReactDOM is temporarily nil

bhauman14:09:20

then reagent.dom.global$module$react_dom will always be nil

bhauman14:09:31

but when is this happening?

bhauman14:09:44

on first load?

pesterhazy14:09:48

no, normally in the browser on first load

pesterhazy14:09:18

but the theory rings true to me

bhauman14:09:54

@mfikes is aware of this problem

pesterhazy14:09:28

so the way the module reference is fixed at ns init time is in conflict with the fact that goog.require is async

bhauman14:09:42

thie problem is caused by figwheel taking over the loading process once its been loaded

pesterhazy14:09:42

I didn't even know that goog.require can be async

bhauman14:09:05

well things are supposed to be loaded ahead of time

bhauman14:09:13

before you get there

pesterhazy14:09:21

right, that's what I assumed

bhauman14:09:47

So that’s the behavior I’d look at

pesterhazy14:09:54

in fact, once the code gets to the point where the exception is thrown, react is already loaded

pesterhazy14:09:23

(defn ^:export main []
  (js/console.warn "XXX" js/reagent.dom.global$module$react_dom)
  (r/render [playground.slide/main-ui] (js/document.getElementById "app")))

pesterhazy14:09:33

that's the code that triggers the exception

pesterhazy14:09:11

but the console.warn prints out that the var is correctly set at that stage

bhauman14:09:32

this is tough, I really need to look at delaying taking over the loading

pesterhazy14:09:49

no wait the code that bombs out is actually

reagent.dom.node$module$react_dom.render.call

bhauman14:09:23

looks like caching

bhauman14:09:44

do you have a node build?

bhauman14:09:56

then forget that

pesterhazy14:09:00

not that I know of...

pesterhazy14:09:52

I had a strange encounter before where the compiler asked me to install

npm install --save '@cljs-oss/module-deps'

bhauman14:09:01

well that just looks wrong if reagent.dom.global$module$react_dom = goog.global.ReactDOM; is at the top of the compiled file

bhauman14:09:27

oh don’t install that by hand

pesterhazy14:09:30

I was confused why module-deps was necessary - I'm not using npm integration or anything like that

bhauman14:09:52

you have to have :npm-deps false

bhauman14:09:11

maybe you missed that in a certain situation?

pesterhazy14:09:34

I didn't set that :npm-deps false manually, because I thought that would be the default

bhauman14:09:53

its not a compiler default

bhauman14:09:16

figwheel will add it if you have :npm {:bundles }

bhauman14:09:04

and you shouldn’t need to install @cljs-oss/module-deps by hand ever

bhauman14:09:24

that only means that :npm-deps is not set to false

pesterhazy14:09:34

that fixed it

pesterhazy14:09:37

it works now

pesterhazy14:09:15

when I fixed it, I did two things: I removed node_modules and package.json (which as you say aren't require), and I added a manual :npm-deps false

pesterhazy14:09:29

I don't know which of those two fixed things

bhauman14:09:26

its both really because

bhauman14:09:51

if there is a node_modules present cljs will scan it

bhauman14:09:37

and you really don’t want cljs to do that even if node_modules is there

pesterhazy14:09:13

I'll make a mental note to always explicitly set :npm-deps false from now on

pesterhazy14:09:42

man, thanks for demystifying this, I thought I was losing my mind

bhauman14:09:48

its in the webpack guide but its easy to miss