Clojurians Log v2

has anyone developed any successful strategies / best practices for developing components with devcards that use re-frame state?

I’ve heard someone talking about separating individual re-frame instances in iframes

Reposted from Clojurescript channel for completeness Best I've seen so far can be found at https://github.com/nberger/devcards/blob/iframe/example_src/devdemos/re_frame.cljs with a brief discussion about it near the bmottom of https://clojurians-log.clojureverse.org/re-frame/2016-07-15.html I'm hoping to put some time in this week to get something written up in the re-frame and devcards wikis if I can get something working with it

you could also try my library https://github.com/binaryage/pure-frame, but it has only v0.5 compatible interface

didn’t have need to really advance it further, will probably do with my next re-frame-based project 🙂

@darwin: Are you planning to update pure-frame to match re-frame as it changes (particularly for v0.8)? Or any plans for other divergences? It does look interesting for sure.

I’m not going to maintain it just for the sake of maintaining it. Only if I needed it for my next project (not planned at this point).

frankly I don’t follow new re-frame development closely because I don’t actively work on any re-frame-based project ATM

Sounds reasonable to me. Re-frame v0.8 looks like it will bring a few interesting changes at least.

not a huge fan of having to use iframes etc,

has anyone tried using the same db instance across cards?

(I'm just checking out devcards too so I apologize for being fairly ignorant about how that works as well)

@mattsfrey: If you read through the link, there are a couple demos showing what happens without iframes - I haven't seen anyone come up with a better idea than iframes yet unfortunately, but at least they are limited to only affecting the devcards part.

devcards is a pretty fantastic tool for design and testing so definitely keep trying it and asking questions. The way I used it in the past with re-frame (without iframes) was to design and test reagent components that had no reliance on the re-frame app-db, then wire them up with subscriptions and handlers in the web app - can't test quite as much that way, but I found it forced me to follow a pretty good design that fit very well with re-frame. Maybe try it out that way and see if you need to go further for your purposes.

Yeah so this might be interesting but our app is setup so that there are no subscriptions

we basically create a data namespace that correlates to each view and have functions inside them that wrap reactions to a piece of the db state

and then dereference those functions in the component to access state

so I'm thinking it might be possible to do this by using an intermediary "outer" component which defines the references to these reactions and then passes them dereferenced as props to an "inner" component that just simply does rendering based on those props

@mattsfrey: Sounds like it has potential, that's essentially the way I did things originally - the only things that went into devcards were the "pure" inner components. You still might run into problems with handlers changing the state of other cards, though. I would be interested to hear how well it works for you. Out of curiosity, is there a particular reason you don't use subscriptions in your app?

@mattsfrey: that's an interesting approach, I'd love to see a simple example of what it looks like in practice

The guy who set it up before I started did it this way and I unfortunately haven't had a thorough discussion on the whys of it

but i'm guessing he liked the concept of keeping signals as pure functions versus the global subscriptions system

ah

yeah I had been thinking about something similar

https://gist.github.com/mattsfrey/99c9f26d5b743d08200de780e1e41909

this is sort of the gist of it

(just updated for some mistakes)

just want to throw this out there: https://github.com/bhauman/devcards/issues/105

it looks like it should be part of this discussion

Definitely, thanks Bruce