Fork me on GitHub
#devcards
<
2016-07-26
>
mattsfrey18:07:16

wondering if anyone has any advice about where to locate devcards in ones project, particularly how you are sourcing the components you define in devcards into your application?

mattsfrey18:07:10

to elaborate I am imagining having a set of dev cards that will catalog my UI components, but I'd like to be able to reference the same code when placing components in my app. Is there a way of doing this without having the same code live in two spots and having to make sure they stay in sync?

mattly19:07:15

@mattsfrey: a, thanks for the gist. b) re your previous inquiry, for things like a styleguide, I have a dev.* namespace that doesn't get included in the "production" build but does get included in our edge builds

mattly19:07:03

there's a few extra route handlers declared there for things like the styleguide, docs, prototypes, etc

mattly19:07:13

it's worked fairly well

mattsfrey19:07:32

so your actual component code does live in two files?

mattsfrey19:07:41

and has to be reconciled somehow?

shaun-mahood19:07:31

@mattsfrey: My usual workflow is to start off with my devcards in the same namespace as the component while designing and figuring things out, then I move it out to a dev.* namespace as needed. Where do you want your devcards to be accessible from - production, development, or separate from both?

mattsfrey19:07:56

Maybe I'm not understanding something but I thought the devcard itself holds the component code that will be used there, basically wrapped inside a defcard etc

mattsfrey19:07:08

but I'd want to use the component code as well inside of my app

mattsfrey19:07:19

i.e. to place a modal or button or whatever

mattsfrey19:07:41

which I wouldn't do with it living inside of a defcard etc?

shaun-mahood19:07:39

@mattsfrey: I believe the general approach is to define your component outside of the card itself, then mount the component within the card so that you can work on the design/tests without needing to have the full app framework built around it. At least that's how I've been using it... I don't think it would work otherwise, as part of the appeal of devcards is that you can choose to build/render the cards or not for any build profile, so you can have them accessible at dev time but not affect anything in your production build.

shaun-mahood19:07:11

If you look at the code on the main demos (https://github.com/bhauman/devcards/blob/master/example_src/devdemos/core.cljs), you can see that the individual components are declared using the normal defn and then those functions are used from within each card

mattsfrey19:07:45

Yeah I wasn't looking at this correctly at all lol

shaun-mahood19:07:39

I've been there 🙂 Bruce's talk at strangeloop is excellent if you haven't seen it yet and might help with some of the conceptual stuff https://www.youtube.com/watch?v=G7Z_g2fnEDg

shaun-mahood19:07:20

But I think how devcards works will be a great fit for what you're trying to do in terms of a UI component catalog, it's a joy to work with.

mattsfrey19:07:13

yeah everyone has been raving about it, I'll check the video

mattsfrey19:07:56

thanks for being so thorough and helping me out, my slack interactions the last few days have really helped shape my testing strategy etc

shaun-mahood19:07:47

No problem, I'm glad I could be of some help. Honestly, slack helped me through so many conceptual issues as I got started with the whole Clojure stack - there's so many new and innovative things that it was impossible for me to wrap my head around it all without help. I spent a couple years really interested in it all, been working with it all for about a year and I still feel like a beginner for much of it.

mattsfrey19:07:46

For sure, I just started with clojure and FP in general 3 months ago so I know the feeling 🙂