This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-20
Channels
- # beginners (43)
- # boot (44)
- # chestnut (17)
- # cider (78)
- # cljs-dev (24)
- # cljsrn (16)
- # clojure (84)
- # clojure-dusseldorf (1)
- # clojure-italy (21)
- # clojure-losangeles (2)
- # clojure-russia (140)
- # clojure-sg (2)
- # clojure-spec (8)
- # clojure-uk (16)
- # clojurescript (23)
- # cursive (7)
- # datascript (1)
- # datomic (18)
- # docker (20)
- # ethereum (1)
- # fulcro (16)
- # garden (4)
- # graphql (27)
- # hoplon (9)
- # jobs (4)
- # luminus (34)
- # off-topic (6)
- # om (4)
- # onyx (35)
- # pedestal (3)
- # re-frame (24)
- # ring-swagger (15)
- # rum (6)
- # shadow-cljs (22)
- # spacemacs (8)
- # specter (22)
- # yada (7)
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)))))
([build-ids]
(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 portwell, 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