Clojurians Log v2

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

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

but in the meanwhile ...

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

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

doesn't look quite production ready yet though?

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

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

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

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

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

perhaps because it started as a fork

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

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

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)

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.

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

@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

seems like a good way to start and kick the tires

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

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

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

So we add :standalone.

You have an iframe-component

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

the re-iframe component does the negotiation

It can literally just check the current browser url

for the presence of standalone

oh shoot

re-iframe needs the url

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

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

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

standalone implies no breadcrumbs etc

oh cool

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

re-iframe needs to know the url its rendering

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

it would be nice to decouple it

IMO

not sure I understand

let me find the code...

So I think this is where iDevcardsOptions comes in.

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?

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

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

you can override and compose over the main object

you also have the path

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:

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

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

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

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

:simple_smile: