devcards

Devcards aims to provide a visual REPL experience for ClojureScript https://github.com/bhauman/devcards
escherize 2016-07-14T00:09:25.000063Z

What's the state of the art or how-to for using devcards with screen-wide interfaces?

escherize 2016-07-14T00:09:46.000064Z

so far I've found the "Don't" method to work pretty ok

2016-07-14T12:56:26.000066Z

Anyone here been able to use devcards effectively with re-frame?

macroz 2016-07-14T13:10:35.000067Z

the standard solution at the moment is to wrap the component into iframe

macroz 2016-07-14T13:11:27.000069Z

stateless, noninteractive components don't have trouble of course

2016-07-14T13:39:27.000070Z

@macroz: Cool, thanks! Using "dumb", stateless components seems like a nice approach in general. How does the iframe solution work?

macroz 2016-07-14T13:45:12.000071Z

I didn't go as far as to resort to them myself, I imagine it's just having a separate page for each of your cards and then having an index page that iframes the parts so that you have one big guide

macroz 2016-07-14T13:45:29.000072Z

that's not as nice as it could be, maybe someone has a better solution

macroz 2016-07-14T13:47:19.000073Z

there seems to be some work for the support here https://github.com/bhauman/devcards/compare/master...nberger:iframe-devcard

macroz 2016-07-14T13:48:28.000075Z

also perhaps re-frame will go from global state to somewhere in the future, who knows 🙂

2016-07-14T13:50:34.000076Z

@macroz: Thanks again for the help! I read through some issues on devcards and re-frame and it indeed seems like there is at least some plan to avoid global state in re-frame at some point

macroz 2016-07-14T13:50:38.000077Z

@nberger: I believe you have done the "devcard iframe" support? how is it going?

2016-07-14T13:51:26.000078Z

@macroz: So you're mostly taking the dumb/skinny/stateless component approach for re-frame and devcards?

macroz 2016-07-14T13:51:29.000079Z

yeah I was quite happy even without the interactivity, my component guide contains static rendered states and the interactivity can mostly be tested in pure handler logic

macroz 2016-07-14T13:51:57.000080Z

so there's always a presentational component to document/render in different states

macroz 2016-07-14T13:52:03.000081Z

that is a pure function

macroz 2016-07-14T13:53:01.000082Z

handlers can be tested as pure functions

macroz 2016-07-14T13:53:13.000083Z

I test the interaction of it all in the app itself until there is a solution

2016-07-14T14:27:40.000084Z

@macroz: Is this the right idea?

macroz 2016-07-14T14:28:32.000086Z

yeah

macroz 2016-07-14T14:28:50.000087Z

if the list doesn't have much to itself, I may skip it and just have one task

macroz 2016-07-14T14:29:08.000088Z

but sometimes there's styling to it that is useful to add

macroz 2016-07-14T14:29:57.000089Z

this is generally the approach from React https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.jop8u2ghm

2016-07-14T14:30:46.000091Z

@macroz: Thanks again for the help. I actually just started reading that article when searching for info on this stuff!

macroz 2016-07-14T14:31:36.000092Z

np, I think that general idea is worthwhile and well explained there

macroz 2016-07-14T14:31:58.000093Z

once you start on that path you'll notice that you can build higher order components nicely that do much of the "container" stuff

macroz 2016-07-14T14:32:33.000094Z

e.g. wiring from a certain path in the state

nberger 2016-07-14T15:08:16.000095Z

@macroz: @curlyfry yes, I've been using devcards with re-frame from that branch. It's far from being perfect but it works. We use it for an app that is in production, we have devcards in 6 different namespaces, some of them include around 10 devcards. It's nice to be able to have them on the same page, rendering components in different states and being able to interact with them isolated from each other

nberger 2016-07-14T15:11:37.000096Z

There is a namespace with some simple examples if you want to play with them