Fork me on GitHub
#re-frame
<
2015-11-14
>
tord13:11:34

I love re-frame, but I can no longer live without devcards. Has anyone found a good way to use devcards with re-frame?

tord13:11:43

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.

mikethompson19:11:38

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

mikethompson19:11:33

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.

tord19:11:24

@darwin: Looks interesting, but I'd prefer to avoid using a fork, if possible.

darwin19:11:24

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.

tord19:11:35

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

tord19:11:08

It sounds like the next re-frame will solve all my problems, though. simple_smile

tord19:11:35

@darwin: Yes, devcards as mini-apps is what I want.

mikethompson19:11:38

@tord the next version of anything solves all known problems simple_smile

mikethompson19:11:52

relationship, job, library simple_smile

tord19:11:05

Cool. When can I start using it? simple_smile

darwin19:11:28

@mikethompson: a suggestion: don’t only make app-db pluggable, also make event-loop somehow “pluggable"

darwin19:11:07

(in next version)

mikethompson19:11:25

Yep. The trick with all this is to avoid "pass down hell"

darwin19:11:44

I see what you mean simple_smile

darwin19:11:07

I converted pretty large codebase to Stuart Sierra’s component model recently simple_smile

darwin19:11:25

It was a hell passing “contexts” all the way down to last tiny helper functions

mikethompson19:11:10

@darwin Yes, exactly.

roberto19:11:12

I don’t understand what devcard should be used for, other than demos. Haven’t seen it applied to a dev workflow.

mikethompson19:11:59

@darwin: so I'm thinking the solutuon is to use something similar to React context

mikethompson19:11:09

Perhaps a reagent version of it

darwin19:11:16

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

mikethompson19:11:35

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

darwin19:11:53

have you guys seen Sierra’s talk on component? He ported component to cljs recently (september)

darwin19:11:01

it is worth looking at

mikethompson19:11:02

I haven't seen it

tord19:11:24

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

roberto19:11:39

yeah I saw the presentation

tord19:11:40

But this is drifting off-topic, there is already a #C09GR9UJC channel.

roberto19:11:49

it looks impressive, but I can’t see how it is applied to the dev workflow

roberto19:11:00

it looked like just demo candy to me

darwin19:11:11

this one: https://www.youtube.com/watch?v=13cmHf_kt-Q it is the second one (updated talk from previous year)

darwin19:11:29

now all that stuff is applicable to cljs as well

roberto19:11:48

oh, didint know you coud use component with cljs now

mikethompson19:11:49

I'll watch tonight. (Morning here)

roberto19:11:32

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.

darwin19:11:27

@mikethompson: also please don’t miss this paragraph relevant for library authors: https://github.com/stuartsierra/component#notes-for-library-authors

darwin19:11:44

you don’t want to force component library onto your library users

darwin19:11:03

you just want to give them enough tools to let them wrap your stuff into their own components if they chose so

gadfly36119:11:33

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

roberto20:11:44

so, this is just for prototyping? It isn’t something you use in your actual project? It is what I’ve understood all along.

tord20:11:24

No, you probably wouldn't want to use devcards in the actual app, if that is what you're asking.

roberto20:11:50

ok, so it is just for prototypes and explaining a POC.

gadfly36120:11:55

Yeah, prototyping, testing, documenting, and sharing with design team are my use cases

roberto20:11:58

then it makes sense if it is for that

tord20:11:05

Exactly, that's it.

roberto20:11:30

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.

roberto20:11:05

which made me wonder if devcards was somehow supposed to be embedded in the real ap

gadfly36120:11:55

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.

mikethompson20:11:09

@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

mikethompson20:11:53

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

roberto20:11:12

Oh man, more js libraries to keep up with.

mikethompson20:11:37

React has been out for 2 years!! Has to be surpassed soon simple_smile

gadfly36120:11:05

Hahaha yuup, its about that time

roberto20:11:13

yeah, I’m surprised node hasn’t been buried by now.

roberto20:11:20

considering the short lifetime of js projects

mikethompson20:11:57

All the three above are very similar and represent the next step.

mikethompson20:11:31

The next step beyond "Flux" style React architectures

mikethompson20:11:50

More towards Elm

roberto20:11:19

redux looked more like Elm also

mikethompson20:11:32

redux looked like reframe !

mikethompson20:11:42

middleware, subscribe, etc.

roberto20:11:51

yeah, which reminds me of Elm

mikethompson20:11:09

Elm has no concept of middleware

mikethompson20:11:24

Elm does not do subscribe

darwin20:11:33

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.

mikethompson20:11:37

BTW, good news: I already know what the step beyond Cyclejs/Motercycle/Yolk will be.

darwin20:11:41

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

darwin20:11:47

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.

darwin20:11:41

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