This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aatree (1)
- # admin-announcements (6)
- # alda (3)
- # beginners (66)
- # boot (41)
- # cider (4)
- # cljsjs (3)
- # cljsrn (18)
- # clojure (146)
- # clojure-android (2)
- # clojure-nl (1)
- # clojure-russia (35)
- # clojure-sdn (2)
- # clojure-sg (5)
- # clojure-uk (41)
- # clojurescript (116)
- # datomic (12)
- # dirac (40)
- # docker (2)
- # editors (2)
- # hoplon (85)
- # immutant (19)
- # jobs (1)
- # keechma (2)
- # lein-figwheel (8)
- # mount (33)
- # off-topic (1)
- # om (114)
- # onyx (159)
- # parinfer (24)
- # proton (3)
- # reagent (4)
- # ring-swagger (15)
- # uncomplicate (7)
- # untangled (93)
- # yada (30)
How hard would it be to adapt yurt so that it could be used with clojurescript? I'm going to need a unique yurt for each devcard. Is this just better suited for using component?
theoretically it should work for development, the way it is written currently won't work in the
from not thinking too deep about it, I don't think it is hard to make it work for
I honestly did not think there is an interest of
cljs , but the point is valid
For the main application it doesn't. I can some it being somewhat helpful for testing.
I have not used devcards, but it would be strange to architect an app in one way to work with devcards and in another way to work in prod? I might be missing something?
The problem would be that each devcards is kind of like it's own self-contained thing running. It would need references to mount states, and multiple devcards would clobber each other's states.
take a look at
yurt sample app: https://github.com/tolitius/yurt/tree/master/dev/clj
two gotchas are: * https://github.com/tolitius/yurt#stop-functions * passing states to functions: https://github.com/tolitius/yurt/blob/master/dev/clj/neo/www.clj#L20
the first one is not a problem, since you can return a map from
start functions that would later be passed on to
in mount you would probably just require it use it: i.e. (`require [app.db :as db]` ...
(routes ... (GET "/foo" (do-somm-with db))))
since by the time the
yurt is created it is completely detached from existing vars, so you can create more
the whole idea was to prove that Clojure vars are not bad and can be also used to build multiple systems within the same runtime
My app had a fair bit of dependency injection already. I'll probably just not use mount for the devcards part. I don't think it is that critical to make it work.
yea, sorry, I might need to blog about it a little bit. I really did not think there would be any interest in
yurt and wrote it specifically for a Clojure Remote talk to prove the point, but I see there are several people who actually like it and want to use it.. /needs thinking
devcards is kind of a unique case, because it's not quite deftests where you are using fixtures, or starting/stopping at the test boundaries. It can continue running
yep, makes sense. can you give a simple example of two devcards that won't work together (to amplify the thinking)?
It would be using om next and datascript. I would assume that the two devcards would be using the same datascript instance, which isn't what you'd want.
just wondering... can two devcards be created with a different config? (i.e. datascript connection string..)
I would assume they'd both still be referencing the same mount state though, say client.db/conn
I presume this is the core point / feature of devcards but.. what would be the reason of having two different devcards.. i.e. how are they different?
Sometimes to see how things change based on different configurations. I guess you could just go with one card per page.
I guess it's a choice between having multiple cards or having mount. It might make more sense just to have single cards for components. I have usually just had one anyways. I wouldn't be able to put any deftests on them, but they could go on separate pages where I could control the mount start/stop more explicitly.