This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-21
Channels
- # admin-announcements (4)
- # aleph (1)
- # beginners (15)
- # boot (55)
- # braveandtrue (5)
- # cider (20)
- # clara (10)
- # cljs-dev (13)
- # cljsrn (8)
- # clojure (52)
- # clojure-austin (30)
- # clojure-brasil (2)
- # clojure-india (1)
- # clojure-italy (2)
- # clojure-nl (1)
- # clojure-russia (72)
- # clojure-sdn (9)
- # clojure-taiwan (2)
- # clojure-uk (45)
- # clojurebridge (3)
- # clojured (1)
- # clojurescript (46)
- # core-matrix (1)
- # cryogen (1)
- # cursive (43)
- # datascript (12)
- # datomic (57)
- # devcards (54)
- # emacs (6)
- # funcool (21)
- # hoplon (335)
- # jobs (15)
- # jobs-rus (40)
- # ldnclj (2)
- # lein-figwheel (20)
- # off-topic (59)
- # om (157)
- # onyx (29)
- # parinfer (2)
- # pedestal (26)
- # proton (9)
- # protorepl (2)
- # reagent (3)
- # ring-swagger (4)
- # spacemacs (2)
- # untangled (17)
I'm also using re-frame and it would be very nice to be able to devcard components that use subscriptions
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
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
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
@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
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
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
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
I mean, devcard options gives access to the original arguments, right? but I think we need something that's not in the original arguments