Has anyone had an issue with figwheel not hot loading unless the browser is in focus? I’ve recently changed from using emacs to intellij and that seems to be the only thing that’s changed. I definitely haven’t made any changes to project.clj that should change the nature of figwheel.

@decim Do you save files manually? Because IDEA by default saves files when it loses focus, and it you didn't save the files yourself, the focus change will trigger figwheel.

@p-himik That would be it. I’m using emacs bindings and unbeknownst to me C-x s doesn’t save. 😃 Thanks

@decim you can try this to save files automatically: https://github.com/bbatsov/super-save

@decim actually, no, I just read you're using IDEA now, so forget about my comment 🙂

hey all! I just finished up a little re-frame project, but I'm having a slight issue deploying.

I run lein cljsbuild once min and then push to gh-pages on github

https://jimtheman.github.io/Jims-ClojureScript-Bakery/

It works, but in the console I see an error every second that figwheel cannot connect

Also, would be nice to hide the re-frisk thing in production.

Can someone point me to how to do this? Is it config.cljs?

did you stop figwheel and clean before building?

thanks, I'm getting a strange error now

Uncaught Error: No *print-fn* fn set for evaluation environment

That happens when you try and call (println) and (enable-console-print!) hasn't been called

It's probably best not to print anything in production mode though

so I guess there's a stray println somewhere

I thought I had deleted them all...

but adding the enable-console-print worked 🙂

it seems to be working now! Although I am getting a new strange error

Uncaught TypeError: Cannot read property 'A' of null

Are you using advanced compilation?

This looks like an advanced compilation error

When you access external javascript you need to provide externs which stop the closure compiler minifying the names

https://github.com/cljsjs/packages/wiki/Creating-Externs

There are a bunch of ways of avoiding this which can be a bit of a pain

I like to use cljs-oops

https://github.com/binaryage/cljs-oops

when interopping with javascript

hmm I'm using :optimizations none and am only really using cljsjs libs

here is my project.clj

(defproject bakery-app "0.1.0-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.8.0"]
                 [org.clojure/clojurescript "1.9.908"]
                 [reagent "0.7.0"]
                 [re-frame "0.10.4"]
                 [garden "1.3.2"]
                 [ns-tracker "0.3.0"]]

  :plugins [[lein-cljsbuild "1.1.5"]
            [lein-garden "0.2.8"]
            [lein-less "1.7.5"]]

  :min-lein-version "2.5.3"

  :source-paths ["src/clj"]

  :clean-targets ^{:protect false} ["resources/public/js/compiled" "target"
                                    "test/js"
                                    "resources/public/css"]

  :figwheel {:css-dirs ["resources/public/css"]}

  :garden {:builds [{:id           "screen"
                     :source-paths ["src/clj"]
                     :stylesheet   bakery-app.css/screen
                     :compiler     {:output-to     "resources/public/css/screen.css"
                                    :pretty-print? true}}]}

  :less {:source-paths ["less"]
         :target-path  "resources/public/css"}

  :repl-options {:nrepl-middleware [cemerick.piggieback/wrap-cljs-repl]}

  :profiles
  {:dev
   {:dependencies [[binaryage/devtools "0.9.4"]
                   [day8.re-frame/trace "0.1.19"]
                   [figwheel-sidecar "0.5.13"]
                   [com.cemerick/piggieback "0.2.2"]
                   [re-frisk "0.5.3"]
                   [cljs-ajax "0.7.3"]
                   [reagent-material-ui "0.2.5"]
                   [bootstrap-cljs "0.28.1-0"]
                   ]

    :plugins      [[lein-figwheel "0.5.13"]
                   [lein-doo "0.1.8"]]}}

  :cljsbuild
  {:builds
   [{:id           "dev"
     :source-paths ["src/cljs"]
     :figwheel     {:on-jsload "bakery-app.core/mount-root"}
     :compiler     {:main                 bakery-app.core
                    :output-to            "resources/public/js/compiled/app.js"
                    :output-dir           "resources/public/js/compiled/out"
                    :asset-path           "js/compiled/out"
                    :source-map-timestamp true
                    :preloads             [devtools.preload
                                           day8.re-frame.trace.preload
                                           re-frisk.preload]
                    :closure-defines      {"re_frame.trace.trace_enabled_QMARK_" true}
                    :external-config      {:devtools/config {:features-to-install :all}}
                    }}

    {:id           "min"
     :source-paths ["src/cljs"]
     :compiler     {:main            bakery-app.core
                    :output-to       "resources/public/js/compiled/app.js"
                    :optimizations   :advanced
                    :closure-defines {goog.DEBUG false}
                    :pretty-print    false}}

    {:id           "test"
     :source-paths ["src/cljs" "test/cljs"]
     :compiler     {:main          bakery-app.runner
                    :output-to     "resources/public/js/compiled/test.js"
                    :output-dir    "resources/public/js/compiled/test/out"
                    :optimizations :none}}
    ]}

  )

for the min build you're using :optimizations :advanced

ah ok

you can try switching it out for :optimizations :none which should help determine if it's definitely an advanced compilation error

ok I'll try that

I have to leave my house now actually, but thanks a lot for the help 🙂

good luck!

Working through the todomvc sample code, the hardest thing to wrap my head around so far is subscriptions and the signal graph stuff. (The infographic is helpful though.) Is there a heavy runtime benefit to structuring things in this way once an application becomes sufficiently complex? So that only the smallest part of the model is used for recalculating the view?

Correct me if I’m wrong but I’ve always though more about re-frame as a sane way to separate out concerns v.s. focused on runtime performance. Now, if you properly separate out concerns then you tend to get faster runtime performance, but I don’t think that performance is a design goal.

That's fair, then the question can morph to "maintainability benefit". 😉 My perspective is colored is this regard by my experience with Elm, where the view is direct function on the model, rather than moving through a subscription layer. By contrast, re-frame feels like more upfront work, but that often means a payoff later on down the road. This isn't a criticism, just my efforts at understanding the design philosophy.

@andrew354, @danielglauser is right that it’s more about separating out concerns,

one of the benefits of having separate subscriptions is that your views are no longer tied to the structure of your database, you can refactor it without touching your views

It’s also a good place to put common logic, and to derive higher level information about your application than the raw db

Yeah, that was one of the interesting things I've noticed in the level 2 vs 3 subscription handlers, where the level 2 is run on every update but is merely access, whereas computation is "deferred" to level 3. Assuming that's a semi-correct understanding, I think is where I picked up on the idea that there was a performance benefit, since computation on unchanged portions of the db will not be run.

For structural decoupling, the benefit is that changes to the structure will only imply rewriting the subscription layer? Rather than the view.

Yep, exactly. The performance benefits are certainly nice, but it's the semantic benefits that are the really useful part

Has there been previous discussion of dispatch returning a promise?

I often find myself wishing that were the case

Thanks @danielcompton. Talking through it here and drawing some stuff on a whiteboard has proven helpful in nailing down the pattern of data flow.