This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-16
Channels
- # 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?
@taylor.sando: good question..
theoretically it should work for development, the way it is written currently won't work in the :advanced
mode
from not thinking too deep about it, I don't think it is hard to make it work for :advanced
mode
That's not a huge deal for devcards not to have advanced mode
I honestly did not think there is an interest of yurt
in cljs
, but the point is valid
For the main application it doesn't. I can some it being somewhat helpful for testing.
You could get away with it potentially if there was only one devcard per page.
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 stop
functions
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 yurt
s
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.
I'll just the workflow using mount and see if I like it.