devcards

Devcards aims to provide a visual REPL experience for ClojureScript https://github.com/bhauman/devcards
macroz 2016-03-21T09:37:13.000009Z

I'm also using re-frame and it would be very nice to be able to devcard components that use subscriptions

macroz 2016-03-21T09:37:40.000010Z

though I also thought of rewriting re-frame with non-global state

macroz 2016-03-21T09:37:45.000011Z

but in the meanwhile ...

2016-03-21T11:01:23.000012Z

@macroz: https://github.com/binaryage/pure-frame

2👍
macroz 2016-03-21T11:04:02.000014Z

yeah, that's interesting I think I bumped into your library sometime months ago

macroz 2016-03-21T11:04:10.000015Z

doesn't look quite production ready yet though?

2016-03-21T11:29:38.000016Z

we would have to talk about specifics, it has been suitable for my needs, re-frame is pretty simple pattern

macroz 2016-03-21T11:42:48.000017Z

I find it a bit confusing at the moment that what is the relation to re-frame, the versions, what it does and how to use it

macroz 2016-03-21T11:43:26.000018Z

production quality would mean that I can point someone to the docs and they can learn to use it

macroz 2016-03-21T11:43:45.000019Z

I can of course read the code and did some of that already

macroz 2016-03-21T11:45:23.000020Z

now it looks like a mix of re-frame and something else which is not a sum of its parts but rather missing something and providing a little bit of the old as well

macroz 2016-03-21T11:45:40.000021Z

perhaps because it started as a fork

macroz 2016-03-21T11:46:24.000022Z

cleaning away all references to re-frame except for inspiration and writing similar extensive README would solve all of that

macroz 2016-03-21T11:47:03.000023Z

but I'll definitely take a look again when I get that far with my own idea, it's good material

macroz 2016-03-21T11:48:48.000024Z

philosophically I like to think that there is a place for re-frame like global state but kiss libraries (e.g. also mount vs. component)

nberger 2016-03-21T14:16:06.000025Z

pure-frame looks really great, I think it fixes the big issue of re-frame: global state. I saw there's an issue in re-frame to incorporate those ideas, and I look forward to it. I wish I had time to try to help there. Given said that, we already have a not-small re-frame codebase, and every time we discussed it, we decided to wait and keep with re-frame, instead of switching to pure-frame.

nberger 2016-03-21T14:18:11.000026Z

At the same time, we really wanted to be able to create devcards, so our pragmatic approach was to add this feature to devcards: the ability to mount each card in an iframe. At first it sounded a bit crazy, but we started to see it as the natural solution to global state... it works for us, and hopefully it will work for other people

bhauman 2016-03-21T14:38:00.000027Z

@nberger I may be seeing this wrong but I think this can be done by simply adding :standalone to devcards and then composing over devcard functionality with an external library

bhauman 2016-03-21T14:38:15.000028Z

seems like a good way to start and kick the tires

bhauman 2016-03-21T14:40:13.000029Z

@nberger: if not, its probably better for me to look at why that wouldn't be possible and fix that

nberger 2016-03-21T14:51:36.000030Z

@bhauman that would be great, much simpler... the thing is how to know whether we are rendering the devcard wrapper or the devcard content. The wrapper is responsible for showing the devcard title (that links to a url for that single card) adding the border, and finally rendering the iframe tag. The content is what's rendered when the iframe src url is hit... Under this scenario, I couldn't see how to do it as a external library, because changes in the routing system are needed to "detect" whether the single devcard should be rendered in the context of the devcards system (breadcrumbs, devcard title, etc), or if just the devcard content should be rendered (the iframe content)

nberger 2016-03-21T14:52:39.000031Z

So I see it as the devcard has two "rendering modes": the devcard wrapper and the devcard content, or something like that

bhauman 2016-03-21T14:53:55.000032Z

So we add :standalone.

bhauman 2016-03-21T14:54:18.000033Z

You have an iframe-component

bhauman 2016-03-21T14:55:13.000034Z

(defcard reframer-card (re-iframe (reframe code ...)))

bhauman 2016-03-21T14:55:44.000035Z

the re-iframe component does the negotiation

bhauman 2016-03-21T14:56:06.000036Z

It can literally just check the current browser url

bhauman 2016-03-21T14:56:19.000037Z

for the presence of standalone

bhauman 2016-03-21T14:57:23.000038Z

oh shoot

bhauman 2016-03-21T14:57:32.000039Z

re-iframe needs the url

nberger 2016-03-21T14:57:34.000040Z

but if the url is going to be the devcards.html url + some fragment url (like the rest of the devcards routing system), then we need some other parts of the devcards system to be aware of the :standalone thing, so the breadcrumb is not rendered, etc...

nberger 2016-03-21T14:59:39.000041Z

so extending a bit more on the previous idea, it's not only that the devcard has to be aware that it's being rendered as standalone or not, also the system responsible for the dir-list, breadcrumb, etc. needs to be aware too...

bhauman 2016-03-21T15:00:09.000042Z

I'm definitely saying that standalone would need to be added with all of its functionality

bhauman 2016-03-21T15:00:32.000043Z

standalone implies no breadcrumbs etc

nberger 2016-03-21T15:01:02.000044Z

oh cool

bhauman 2016-03-21T15:01:36.000045Z

so the next question is how to we enable a (re-iframe component)

bhauman 2016-03-21T15:02:13.000046Z

re-iframe needs to know the url its rendering

nberger 2016-03-21T15:02:41.000047Z

well, perhaps we can make it independing from the routing system...

nberger 2016-03-21T15:02:50.000048Z

it would be nice to decouple it

nberger 2016-03-21T15:02:55.000049Z

IMO

bhauman 2016-03-21T15:03:47.000050Z

not sure I understand

nberger 2016-03-21T15:03:54.000051Z

let me find the code...

bhauman 2016-03-21T15:05:17.000052Z

So I think this is where iDevcardsOptions comes in.

nberger 2016-03-21T15:06:04.000053Z

in https://github.com/bhauman/devcards/compare/master...nberger:iframe#diff-1e20379ffb0f9dd5ca0f4add2951ee54R604 we are checking if devcard-data has :standalone, and if so we remove :iframe from the devcard, so "the real devcard" is rendered. I'm not super happy of how the standalone option is being passed (via *devcard-data*), so I guess that iDevcardsOptions might help on that?

bhauman 2016-03-21T15:08:42.000056Z

yeah i Devcard options provides you the space to decide wether to render an iFrame or the original

bhauman 2016-03-21T15:09:48.000057Z

you can override and compose over the main object

bhauman 2016-03-21T15:10:02.000058Z

you also have the path

nberger 2016-03-21T15:13:06.000059Z

Oh, I didn't see that, I should think a bit about it... from the first look, I'm not sure how to identify from there whether we are rendering the "devcard wrapper" or the "devcard content (standalone)" content... but I'll think more about it :simple_smile:

bhauman 2016-03-21T15:14:02.000060Z

it intercepts and allows you to change what is being sent to devcards at runtime

nberger 2016-03-21T15:14:03.000061Z

I mean, devcard options gives access to the original arguments, right? but I think we need something that's not in the original arguments

nberger 2016-03-21T15:14:38.000062Z

Hmmm ok, I'll think about it. I have to run now anyways, will come back later with my thoughts

nberger 2016-03-21T15:15:03.000063Z

by the way, thanks for your time, and for devcards :simple_smile:

bhauman 2016-03-21T15:15:30.000064Z

:simple_smile:

2