@mikethompson: Hello, regarding the rant on reddit (https://www.reddit.com/r/Clojure/comments/3vk58p/a_rant_on_om_next/) and your issue on github (https://github.com/reagent-project/reagent/issues/209) I am curious what would be the better approach of writing components in re-frame: 1. parent/manager component that has most of subscribes (all of them?) and then passes down deref. data to children, which in this case, are pure components without any subs. The biggest downside that I see is that the parent component gets re-rendered all the time when subs. change. Advantage - pure children. 2. have subs wherever we want. The downside is that we depend on some subs. path and components become less re-usable. 3. others? Thank you!

@ivanbokii Either 1 or 2 works. I've used both. I've used a hybrid too. The parent passes down ids to the children, which then use those ids in their subscriptions. So I would disagree with your assertion about 2 necessarily creating non-reusable components.

you're right, they are reusable, they are just less reusable compared to 1.

at some point I thought that 2 is considered as an anti-pattern because you always need to clearly understand how re-rendering works (equality for arguments and identity for subs) and sometimes there is a need to regenerate children even if args are the same and subs. didn't change (the {:key *} trick). So you can have pretty tricky situations that can feel complicated and messy. But I guess it's all part of the learning curve and re-frame is a fantastic library to learn! Also, curious about your thoughts on the talk Kris Jenkins gave on the latest Clojure eXchange conf. "ClojureScript: Architecting for Scale". Ideas he presented are very similar to the ones implemented in re-frame. I think @pupeno posted a link somewhere above (https://skillsmatter.com/skillscasts/7227-clojurescript-architecting-for-scale)

Yeah, it is part of the learning curve. i don't have any neat axioms to pass on (yet!)

Regarding Kris' talk, I didn't find much new in it. I feel as if this is now fairly well trodden ground. So there's no novelty in the information and I couldn't see much novelty in implementation, compared to other, existing libraries .

there's already re-frame obviously. Plus ... https://github.com/jamesmacaulay/zelkova https://github.com/hoplon/hoplon etc

@mikethompson: great! thanks for your thoughts and links!

No problem at all. I'm always very glad to share my harebrained ideas and opinions

@mikethompson: the API is looking good. So far everything is working. I hope to wrap up Prerenderer 0.2.0 today or tomorrow.

@pupeno: its going to be very cool. We'll standby to release v0.6.0 of re-frame

v0.6.0 of re-frame currently being pushed to clojars: https://github.com/Day8/re-frame/blob/master/CHANGES.md#060--2015-12-10

@mikethompson: any gotchas upgrading from 0.5.0 ?

As you can see from the changelog, for pretty much everyone there will be no change.

Hi, I started learning about the concepts in re-frame, especially about one app data source

And I am wondering how I should solve following problem: I want to create a component for displaying and editing some entity. re-frame says I should use subscription for accessing the data and handlers for handling events like modification of the data. However, the source of the entity data might be different in different places of the application.

In more traditional approach I would pass the data in to the component because the outer component knows which entity should be displayed by the inner component

For example in a bug tracking app I could have a user entity in many different places (reporter, watcher, assignee etc fields of a bug) and I would need a component like a user picker which would display the current value of the property and allow me to change it

How should I design such a component using re-frame?

The parent component can still pass, via props, the information the child needs to subscribe to the right sources and dispatch the right events?

The parent can pass into the components, the user-id. And the component can subscribe to that user's details, and display them?

I guess I would need to pass not only user-id but also the path in the app-db where the user data is located, right?

I was also thinking about another use case: a router. I saw the example with active panel stored in app-db. And I wonder how I should manage the state of the current view of the route. For example if the current route has a view which should show a list of some kind of entities, I need to store that list somewhere in app-db. But what if I change the view to another route? I would like to have that data removed from app-db as I no longer need it (and probably need another data for a totally different view). Should my handler which changes the current active panel remove that data from app-db?

@piotrek you don't need to pass the path in the app-db if you write a handler function that you can use to update the user info for user-id.

@underplank: I updated the Testing Wiki page a tiny bit. https://github.com/Day8/re-frame/wiki/Testing I now provide 3 ways to test components (none of which I use personally :-))

oh thanks. I’ll take a look

Don't expect too much new. Its really just me noting down what we talked about previously. Structuring it a bit better.

Cool. Yeah I think thats clear on what you are able to do. thanks!