Fork me on GitHub
#figwheel-main
<
2018-08-17
>
onetom04:08:42

@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...

onetom06:08:50

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}))
if figwheel reloads the card, it will actually reflect the updated atom, so the click handler wiring works indeed.

onetom06:08:28

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

onetom06:08:53

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

bhauman12:08:30

@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

bhauman12:08:35

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

bhauman12:08:45

I’m not sure why I designed it this way

bhauman12:08:53

it was a long time ago

bhauman12:08:16

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

onetom17:08:33

i can't think of any benefit of leaving this nice little one-way dataflow mechanism out in the dom-node case. in my mental model, this data atom is the view-model of a card and it's an atom, so it can be monitored and the actual view recomputed from it. it think it's irrelevant whether the view is described as a virtual or actual dom.

onetom17:08:23

the current documentation didn't suggest any different behaviour either and that seemed very intuitive to me too

onetom17:08:57

in case the re-rendering behaviour is undesired, one should just simply not use this initial atom and roll their own state management within the rendered component

zclj12:08:52

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?

zclj12:08:11

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

👍 8
😄 4
❤️ 8
onetom17:08:13

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 🙂

bhauman17:08:25

@onetom that diagram doesn’t exist

bhauman17:08:39

but I have intentions

🙏 4
bhauman17:08:21

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

bhauman17:08:26

I’m curious myself

bhauman17:08:41

rebel-readline is a failrly big startup hit

bhauman17:08:59

the initial code compile is the biggest hit

bhauman17:08:13

the server starts pretty quickly

bhauman17:08:32

and then there is the clojure tools bootstrapping the environment

bhauman17:08:30

everything else shouldn’t even count

bhauman17:08:29

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

bhauman17:08:03

or if the dependencies are particularly heavy to load

john17:08:22

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

onetom17:08:37

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

onetom17:08:08

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

bhauman17:08:12

I would definitely compare with a fresh project as a baseline

onetom17:08:26

the baseline was 10-15seconds

onetom17:08:35

nrepl adds about 4sec to it

bhauman17:08:48

I’m checking the baseline here

onetom17:08:00

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

john17:08:09

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.

john17:08:02

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

onetom17:08:37

sounds like u might have some jvm flags at play

bhauman17:08:38

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

john17:08:27

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

bhauman17:08:51

I just got 7-11 seconds on without rebel

onetom18:08:02

@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.

bhauman18:08:12

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

bhauman18:08:24

and apparently starting nrepl is a big hit as well

onetom18:08:08

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

john18:08:47

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/

👌 4
john18:08:56

You could def pull some inspiration from there.

john18:08:56

This one being the most salient:

onetom18:08:42

Thanks! That's quite inspiring.

john18:08:03

Figwheel's involvement is obviously more complicated

john18:08:30

here's a graph of tools.deps:

onetom18:08:29

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

john18:08:28

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 🙂