@bhauman @iam i was just about to ask about the figwheel.main + devcards story too, because i want to implement it in our company too, so it's very likely that i will be an early adopter of this new :extra-main-files feature. i didn't know about hawk, so thanks for mentioning it. we are usually using http://www.entrproject.org in conjunction with https://github.com/DarthSim/overmind but that's not as programmable as hawk and i was missing the ability to build pipelines of build steps this way. at first glance maybe hawk can help to do that...

i have this devcard using dom-node and it's not updating when the atom is changing:

(defcard my-first-card
  (dom-node
    (fn [data node]
      (let [el (js/document.createElement "h1")]
        (doto el
          (set! -onclick #(swap! data update :counter inc))
          (set! -innerText (-> data deref :counter str)))
        (.appendChild node el))))
  (atom {:counter 123}))

is this an expected behaviour not to re-render on atom change if im using this dom-node macro?

im asking here, because i thought it might be related to using devcards from figwheel.main...

@onetom the atom changing does not cause the card to change in this case https://github.com/bhauman/devcards/blob/master/src/devcards/core.cljs#L348

but you can add a watch in your component to update it.

I’m not sure why I designed it this way

it was a long time ago

I think my thinking was that since this isn’t React you have to manage your changes manually anyway

I'm starting to try out figwheel-main, really liking it over figwheel so far. I have one question about reloads. In a re-frame scenario where I want to clear subscriptions on reloads I have used :on-jsload to point to a reload fn. How should I port that kind of behavior to figwheel-main? Is it https://figwheel.org/docs/reloadable_code.html#setup-and-teardown-pattern that I'm supposed to use?

https://figwheel.org/docs/hot_reloading.html#reload-hooks

@zclj ^

@bhauman Thanks, I'll check it out. And thank you for your hard work with such an awesome tool!

is there some architectural diagram, which explains how figwheel builds, the browser and the clojurescript repl is tied all together? im just wondering how to explain all this to my colleagues concisely enough... i foresee that i must also make an argument why the whole setup takes 20+ seconds to start and i think such a diagram might make them more forgiving 🙂

@onetom that diagram doesn’t exist

yet

but I have intentions

@onetom why do you think its’ taking 20 seconds to start?

I’m curious myself

rebel-readline is a failrly big startup hit

the initial code compile is the biggest hit

the server starts pretty quickly

and then there is the clojure tools bootstrapping the environment

everything else shouldn’t even count

oh here’s the thing, if you have a lot of dependencies, there is a cost for clojure to load all of them on start

or if the dependencies are particularly heavy to load

@onetom It doesn't take 20 seconds on a fresh project, right? I'm not seeing that here.

i've already removed rebel-readline; i don't think that was the culprit. im starting an nrepl server first, so i can eventually interact with the cljs-repl from cursive or vs code

or emacs

and have the same instructions for dealing with the project irregardless what editor someone is using

I would definitely compare with a fresh project as a baseline

the baseline was 10-15seconds

nrepl adds about 4sec to it

I’m checking the baseline here

btw, the code is open source. im talking about this block-explorer branch: https://github.com/enumatech/cljs-abi-viewer/tree/block-explorer

I just ran it on a seemingly medium size project (a few thousand lines of code, very few deps) and it took about 8 seconds for the browser to launch. 2017 MBP though.

The save/compile cycle while repl'ing is usually only 1 to 2 seconds though.

sounds like u might have some jvm flags at play

yep I get the 10-15 seconds with rebel-readline

well, this project has zero deps, actually, outside of fighweel.main, figwheel.repl, cljs and clj

I just got 7-11 seconds on without rebel

@bhauman btw, if you have some rough idea how would you visualize the architecture of figwheel, then just draw it on paper and i might be able to come up with a programmatic digital visualization of it with plantuml, graphviz, tikz or something.

cool 🙂

however the start up time is largely composed of loading clojure code and compiling the clojurescript

and apparently starting nrepl is a big hit as well

Here is an example visualization I made to explain how an Ethereum node, the browser, the dapp in the browser and metamask browser extension is connected

Fogus put together a great set of graphics explaining clojurescript compilation in a few different possible setups: http://blog.fogus.me/2012/03/27/compiling-clojure-to-javascript-pt-3-the-himera-model/

You could def pull some inspiration from there.

This one being the most salient:

Thanks! That's quite inspiring.

Figwheel's involvement is obviously more complicated

here's a graph of tools.deps:

yeah, i know that one. btw, you should just paste image urls. that's more effective, plus everyone would know where did the image come from

aye, sorry. I was just ctrl-v'ing into the text box. Found them on google image search. I'm betting Alex Miller made that last diagram 🙂