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.

right, I understand, but yurt is not really a drop in replacement for mount

there are a couple of gotchas

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

the second one would depend on the way you'd design your app

i.e. for example, do you see how db is passed as a value to make routes?

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 yurts

hence you can't really reference the vars globally in your code with yurt

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.

cool, let me know. meanwhile, I'll read about devcards, thanks for the question though