Clojurians Log v2

Added some more devcards documentation:

http://rigsomelight.com/devcards/#!/devdemos.reagent by @gadfly361

http://rigsomelight.com/devcards/#!/devdemos.custom_cards

@darwin: I'd look at the IDevcardOptions protocol in the docs above

lets you override the path

@bhauman: thanks a lot, will revisit my code soon-ish

@bhauman: while you are at documenting things, I would really appreciate some doc on how to build my initial data only if defcard is going to be displayed - for example look at defcard reagent-support here http://rigsomelight.com/devcards/#!/devdemos.core, what if building re-bmi-data is a heavy-weight operation? I want to build it only if the card is going to be displayed. Maybe passing a function there?

@darwin you can defonce an ratom and pass that in as your initial data

@darwin you can also defonce initial data (a map) and pass that in as well

ok, that would work for figwheel-workflow, but what if I want to do a full refresh for some reason, then I get all the heavy objects from all cards re-created

the issue for me wasn’t really speed, but debug logging

I wanted to focus on one card and ignore others for a while

had to comment-out all my other cards

or push the init code into render function of the component as a quick hack

@darwin: well that seems like the cost of doing business right.

@darwin: but you can focus on one card though, by clicking the heading

that is what I did, but all namespaces get loaded and all init code runs

I would like to have some way how to build init data on-demand, only when devcard is going to be displayed

not sure about tests tough,

they also run all the time I guess

@darwin: there is a figwheel client side flag that isn't documented called :reload-dependents

@darwin: tests only run if the card is mounted

if you set that flag to false then the other ns won't be loaded every time

hm, I will look for some solutions, maybe my workflow was broken, I didn’t use figwheel for this, because my atoms weren’t updated on change for some reason, so I had to do full refreshes

but still the thing that all my devcard init code runs even if I just directly view one devcard is not optimal

@darwin: here is what you can do

I had situations where I broke my code, and wanted to fix it on one particular card, but all were broken giving me hard time debugging it

just create an a react component that initializes your data when it's mounted

Have it take a function

then make that the first card on the page

This is also a good solution for your app. Top level init isn't very good. Enclosing this stuff into a component gives you much more control

ok, will try to something like this, will rewrite my stuff with IDevcardOptions anyway, it will be good opportunity to revisit this

thanks for the hints

there is also Stuart sierras component which works in CLJS now

want to use it, just saw his talk from StrangeLoop few years back

need to rewrite most of my defs this way

but react comps work as well or better

@meow: Just letting you know my strategy for creating a devcards website. Create an index.html at the root of my repository that references built assets in the resources dir. And then create a gh-pages branch from master.

The every so often build the website build and merge it into gh-pages

gh-pages is simply a mirror of my master

@bhauman: I've started using devcards for building out project and technical requirements, it's working really well for it. I prefer it to pretty much all the alternatives I've tried, including markdown based editors, bug trackers and project management software . Just feels so freeing to be able to extend things as far as I want and have everything respond so quickly to changes.

@shaun-mahood: Thats good to hear :simple_smile: Yeah live code and docs together is pretty expressive. I'm glad you are having fun with it.

@shaun-mahood: I'm pretty busy updating the docs

I'm mostly surprised at how nice it is to use it for the simplest things using just defcard and deftest, without anything complex. Docs are definitely coming along too, it's way more understandable and the case for it seems much clearer than when it was first announced.

I have a bunch of work coming up that's outside of clojure / cljs and I'm already feeling depressed about it.

darn, sorry to hear that

I've got plans for eventually getting it all moved over. May be rebuilding one of the apps sooner than later into cljs, so that part will be fun.