Fork me on GitHub
#devcards
<
2016-03-21
>
macroz09:03:13

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

macroz09:03:40

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

macroz09:03:45

but in the meanwhile ...

macroz11:03:02

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

macroz11:03:10

doesn't look quite production ready yet though?

darwin11:03:38

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

macroz11:03:48

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

macroz11:03:26

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

macroz11:03:45

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

macroz11:03:23

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

macroz11:03:40

perhaps because it started as a fork

macroz11:03:24

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

macroz11:03:03

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

macroz11:03:48

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)

nberger14:03:06

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.

nberger14:03:11

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

bhauman14:03:00

@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

bhauman14:03:15

seems like a good way to start and kick the tires

bhauman14:03:13

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

nberger14:03:36

@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)

nberger14:03:39

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

bhauman14:03:55

So we add :standalone.

bhauman14:03:18

You have an iframe-component

bhauman14:03:13

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

bhauman14:03:44

the re-iframe component does the negotiation

bhauman14:03:06

It can literally just check the current browser url

bhauman14:03:19

for the presence of standalone

bhauman14:03:32

re-iframe needs the url

nberger14:03:34

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...

nberger14:03:39

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...

bhauman15:03:09

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

bhauman15:03:32

standalone implies no breadcrumbs etc

bhauman15:03:36

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

bhauman15:03:13

re-iframe needs to know the url its rendering

nberger15:03:41

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

nberger15:03:50

it would be nice to decouple it

bhauman15:03:47

not sure I understand

nberger15:03:54

let me find the code...

bhauman15:03:17

So I think this is where iDevcardsOptions comes in.

nberger15:03:04

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?

bhauman15:03:42

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

bhauman15:03:48

you can override and compose over the main object

bhauman15:03:02

you also have the path

nberger15:03:06

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

bhauman15:03:02

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

nberger15:03:03

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

nberger15:03:38

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

nberger15:03:03

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