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