Fork me on GitHub

@cjmurphy defquery-entity is for queries that are joins on iDents


Which could be from load or load field. The idea is if it's a join on and Ident, then you're asking to start at some specific entity in your database.


Load from the keyword is what Defquwry-root is for, since such a query will load into the root node by default


So, status update on using react libraries from node: I profiled the problems in compile speed and worked with Antonio. That got us back to 2s hot reload, which is good. I tried some other libraries, and the support is still pretty delicate, but it looks like most of the issues are at the Closure level in terms of processing said libraries. Blueprint seems to work ok, but semantic-ui-react doesn’t. Patches for some things are in Google’s court (submitted over a month ago).


@currentoor it gets bad when you run multiple builds. Seems like putting each build on a thread would totally fix that, but I think that would require a figwheel patch…


Oh wait. If you’re using my setup (through sidecar) then you write it so that you can pass a command line option to specify the figwheel server port…then you could set up build configs to run each one on a separate port. It requires hitting “Run” 5 times, but gets you your speedup if you need them all at once.


(defn start-figwheel
  "Start Figwheel on the given builds, or defaults to build-ids in `figwheel-config`."
   (let [figwheel-config (fig/fetch-config)
         props           (System/getProperties)
         all-builds      (->> figwheel-config :data :all-builds (mapv :id))]
     (start-figwheel (keys (select-keys props all-builds)))))
   (let [figwheel-config   (fig/fetch-config)
         port              (some-> (System/getProperty "figwheel.port") Integer/parseInt)
         default-build-ids (-> figwheel-config :data :build-ids)
         build-ids         (if (empty? build-ids) default-build-ids build-ids)
         preferred-config  (cond-> (assoc-in figwheel-config [:data :build-ids] build-ids)
                             (and port (> port 0)) (assoc-in [:data :figwheel-options :server-port] port))]
     (reset! figwheel (component/system-map
                        :css-watcher (fig/css-watcher {:watch-paths ["resources/public/css"]})
                        :figwheel-system (fig/figwheel-system preferred-config)))
     (println "STARTING FIGWHEEL ON BUILDS: " build-ids)
     (swap! figwheel component/start)
     (fig/cljs-repl (:figwheel-system @figwheel)))))
adds support for -Dfigwheel.port=5000, so your run configs just need to specify things like -Dcards -Dfigwheel.port=5000 and then your cards will have their own compiler and URL port


I’m adding that to the lein template right now


well, playing with it I’m not sure it is as significant as I thought it would be. I guess it depends on how many cores you have. I tried various things (even renice on one build to give it priority in the OS) but I could never get my “preferred build” to be as fast as just running it by itself. The competition for resources (probably IO) bottlenecks it. It is still faster than running just one fighweel on multiple builds. My best results were to turn on :parallel-build on the build I cared most about, and off on the others. That gave my preferred one enough of a boost to be within about 12% as fast as running it alone.


Be carefull with :parallel-build this wont notice circular dependencies and then basically just break down. We run 3 builds at once and I always make sure that the thing I am working on is first in the queue then it doesn't really matter


I was just wondering about the difference (between defquery-root and defquery-entity) because I'm loading from a defquery-root without a post-mutation, and yet the data is landing in the right places (in the client state in the joins of a defui subquery component), without any code to shift from the root join. Thinking about it I probably do need to clean up at the root, but the subquery joins are filling up fine (with vectors of idents).


hello! are there any boot templates/projects with fulcro out there? i would like to use it, but run out of ram with leiningen quickly. thanks for this seemingly awesome framework by the way! 🙂


@vyir I’ve seen ppl have more problems with boot (things like slow builds). I don’t maintain one. Solving RAM issues with lein seems pretty simple…e.g. :jvm-opts


@cjmurphy the root queries will be joined from the root node…of course things will normalize properly…but this list of idents will be off of root unless you target them…of course you can always access a root proprtty via a link query. So, not sure which thing you’re doing, but that is separate from the intention of the primitives 🙂


@mitchelkuijpers Thanks for the tip. I didn’t realize that abt parallel builds


@tony.kay My problem was I wasn't passing in the right ident (I was passing in the ident for a panel). Understand load much better now thanks 🙂