This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-25
Channels
- # aws (1)
- # bangalore-clj (9)
- # boot (97)
- # capetown (1)
- # cider (4)
- # clara (1)
- # cljs-dev (2)
- # cljsrn (109)
- # clojure (258)
- # clojure-finland (3)
- # clojure-greece (2)
- # clojure-italy (1)
- # clojure-russia (33)
- # clojure-spec (41)
- # clojure-uk (46)
- # clojurescript (57)
- # component (17)
- # core-async (6)
- # datomic (13)
- # devcards (10)
- # dirac (2)
- # euroclojure (1)
- # figwheel (1)
- # funcool (1)
- # hoplon (472)
- # luminus (17)
- # off-topic (1)
- # om (16)
- # onyx (40)
- # pedestal (14)
- # proton (12)
- # re-frame (27)
- # reagent (15)
- # ring-swagger (2)
- # specter (5)
- # testing (4)
- # untangled (258)
- # vim (4)
adding :devcards true
to my :figwheel config for the build profile didn't work here
oh, wow. I guess I should read a little bit of history before jumping in with the question 🙂
So, it looks like default devcards won't support re-frame. And it doesn't look like @nberger has published to clojars his fork of devcards
@johanatan, @mattly: I couldn't put much time lately on bringing that branch to a "publishable" state. I think it's not very far from having something reasonably usable. My top priority (as soon as I find some time to play with it) is to refactor it to follow the "custom cards" examples, reifying IDevcardOptions
to modify how the card is rendered depending on whether it's being rendered as a standalone card (inside of the iframe) or as part of the devcard system. That should decouple it from deep inside of the devcard system and leave it more as an extension. Once there + some minor polishing, I think it's ready for sending as a PR to devcards or to extract some stuff as PRs for devcards (mainly the routing changes to support the standalone routes, which are the iframe target) and publish the rest as a separate lib.
If anyone wants to help in any way, feel free to send me a DM and we can discuss about it.
@mikethompson: Thanks a lot! I'll look into it today and see what solution I come up with.
@johanatan @mattly I know this is the reframe channel, but if you want to use devcards there are alternatives to reframe. Not being able to use cards was the smell that made me look for other options.
Smell? re-frame is a framework rather than a library and that has been a very deliberate decision. There are pros and cons.
I could easily make re-frame a library. But there would be consequences (smells?) to that as well.
So that "smell" of which you talk has been much thought about and considered, I assure you.
Hey Mike! I'm on a really poor wifi + mobile right now. I'd love to chat about this later if you're up to it. I didn't mean to offend, sorry.
All good. I'd love for there to be a solution for devcards but just in a way that doesn't cost in other important areas.
There is also the small matter that I don't tend to use devcards (I find figwheel almost takes away the need) so I haven't personally been tempted to fix this.
as much as I'd like for re-frame to not rely on global state, perhaps binding it to the component or such, what it offers in event/data flow is more than worth the trade-off
@mikethompson: Read your response and it is now crystal clear. Thanks again! I think this message https://clojurians.slack.com/archives/re-frame/p1477338381004617 can be added to the documentation basically unedited 🙂
@kauko: does this mean that if you are a re-frame heretic like myself and only using global data/event stream for high order concerns that devcards may work as is?
And btw devcards would be immensely useful in my application as it has grown to a level of complexity such that navigating to various parts of the UI to test the different 'modes' of my re-usable components is taking a non-negligible amount of time. Would be much more efficient to see them side by side on a lab table such as devcards provides.
Also interestingly/ironically enough, it is this re-use of components primarily that inspired my re-frame heresy
@johanatan that's exactly why I went the iframe route: I wanted to render multiple devcards in the same page, representing different states of a complex app, allowing me to even interact with it in some cases so I wanted all my handlers and subscriptions hooked up, and it was not an option to not use re-frame. And the iframe implementation worked pretty well for us