This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # beginners (7)
- # boot (30)
- # clara (1)
- # cljs-dev (3)
- # clojure (57)
- # clojure-austin (2)
- # clojure-conj (3)
- # clojure-dev (11)
- # clojure-russia (84)
- # clojurescript (105)
- # data-science (1)
- # devcards (1)
- # editors (4)
- # editors-rus (2)
- # hoplon (119)
- # immutant (1)
- # lein-figwheel (5)
- # off-topic (4)
- # om (6)
- # re-frame (75)
- # reagent (5)
I love re-frame, but I can no longer live without devcards. Has anyone found a good way to use devcards with re-frame?
The best idea I can think of is to get rid of the global app-db and instead pass an app-db as a parameter to all components as well as to subscribe and dispatch, but that seems awkward. It would also force me to modify re-frame itself, which I'd rather not do.
@tord when developing, I use figwheel and techniques like this: https://github.com/Day8/re-frame/wiki/FAQ#5-how-can-i-inspect-app-db I was under the impression that gave me most of what devcards delivered. BUT I've not used devcards for a long time. Is there something else I'm missing, perhaps something new?
But, to answer you question, the next version of re-frame will have a way to remove/abstract
app-db. I think. Been dwelling on that one for a while.
I think he needs for each devcard own isolated re-frame instance. Or sometimes share handlers but have different app-dbs. That way each devcard can act as an independent "mini-app” exercising only selected subset of app functionality.
@mikethompson: I like devcards for the ease of interactive and fluid testing and documentation. It's much more than just visually inspecting the app-db. Have a look at the example devcards on Bruce's site to see how it all works:
@mikethompson: a suggestion: don’t only make app-db pluggable, also make event-loop somehow “pluggable"
I don’t understand what devcard should be used for, other than demos. Haven’t seen it applied to a dev workflow.
@darwin: so I'm thinking the solutuon is to use something similar to React context
but when you go down that rabbit hole, at the end you get pretty flexible system, for testing, devcards and similar needs, because nothing is referenced directly from global scope
Right now you
(dispatch ....) and we'd like to move to
(dispatch context .....) ...... but not have to pass that context down through all the heirarchy
have you guys seen Sierra’s talk on component? He ported component to cljs recently (september)
@roberto: It's hard to explain, it's something you just have to experience for yourself. If the example devcards on the main site are not enough for you, have a look at this presentation by Bruce Hauman himself:
this one: https://www.youtube.com/watch?v=13cmHf_kt-Q it is the second one (updated talk from previous year)
i would really like if you could just restart a component instead of the entire system tho. But I understand it is very difficult problem.
@mikethompson: also please don’t miss this paragraph relevant for library authors: https://github.com/stuartsierra/component#notes-for-library-authors
you just want to give them enough tools to let them wrap your stuff into their own components if they chose so
@roberto i initially overlooked devcards bc i thought it was just some unneeded flash. However, i no longer feel this way. I've been using devcards to mock up an interactive example that lives outside the scope of my main application. Ive found that by easing seeing the components state and response to events has sped up my dev cycles. Also, this is really helpful for sandboxing components and allowing design team to see the result and tweak it.
so, this is just for prototyping? It isn’t something you use in your actual project? It is what I’ve understood all along.
No, you probably wouldn't want to use devcards in the actual app, if that is what you're asking.
Yeah, prototyping, testing, documenting, and sharing with design team are my use cases
I was getting mixed messages between what I understood, and what I thought other people were saying: that devcards is the future for developing apps.
Yeah, i can see how it can all get opaque. Devcards are typically their own independent build, in additon to dev and prod if that helps how to think about it.
@darwin: on a completely different topic .... if anyone wants to keep up with the current state of play in all this. I'd encourage you to keep an eye: - Cycle.js - https://github.com/garbles/yolk
There's also a motorcycle.js which is the React version of Cycle.js (which uses virtualdom instead of React). But they seem to have taken down there repo .... or I can't find it
my explanation: devcards is a lab, independent from your main app, where you can explicitly instantiate parts of your app, set them into required distinct states and visually represent that state (for example you display key react component in particular states in a separate HTML page). this has two great consequences: it gives you great bandwidth for testing those states, because thanks to figwheel (optional) you get magic feedback loop when you perform code changes and you get instant visual feedback for all those states. Second, it forces you to develop in a style where your app is not a monolithic piece of code. It must be possible to instantiate app independently multiple times and set its state somehow easily. I would say, similar thing to writing testable code, or writing reloadable code (for figwheel). If you don’t do that from beginning it is hard to switch to it later when you already have larger codebase not aware of it.
BTW, good news: I already know what the step beyond Cyclejs/Motercycle/Yolk will be.
Devcards are currently implemented as a SPA (single JS context), so that is a problem for re-frame (and many other libraries), because you would like to have one re-frame instance per devcard and host multiple devcards in a single page (single js context).
I think a devcards version using one IFRAME per devcard would solve it. You would simply get clean env to setup your app and would not have to care about other copies living in the same context.
I wonder if @bhauman considered this ^^, it would be easier for people to start with devcards, but on the other hand it woudn’t force them to structure their apps in a better way. And would not benefit @bhauman, I guess, because he is already writing his apps to be "devcard-able" from day-1