Great conversation; I'll just add that I think it's a pretty fundamental part of re-frame (as I see it, thinking about the "materialized views all the way down | derived data all the way down | streams everywhere | however you want to sell it" approach that is behind re-frame and samza) that there is a _single_ app db from which the entire app emanates. (Of course, we have Mike T. himself here in this thread so he's welcome to object or qualify his own vision here :-)) It's what (as Mike T. pointed out) what's behind the glitch free semantics of re-frame, and brings with it some nice conceptual properties. Of course, your criteria of building aspects of the app as independent "modules" raises an interesting question about how you handle state in such a situation. As I see it, there are a couple of approaches to this problem:
* Have the top level of your application state (app-db, whatevs) reflect the collection of modules that you have in the application. So maybe it would be a map with keys corresponding to your different modules. You could build up helpers around this structure which make it fairly straight forward to add module data to the top level app db. There's still a bit of thinking to do regarding how you orchestrate/register the handlers for each of these modules (ideally this would be deterministic as far as state updates go). But there are already a lot of ideas in this thread which can be applied towards a solution given this app-db structure (methinks). * If datascript/datomic are appealing to you, you could use a datascript db on the client together with qualified attribute names reflecting the module breakdown. If you set things up right, you don't really have to think about "organizing" data for one module versus the other. You can look into the posh library which gives you some nice tools for creating reactive datascript queries (materialized views/signals/etc) for use in your reagent components. It's really quite lovely :-) However, at the moment it's not out of the box interoperable with everything in re-frame. But we're currently in the process of figuring out how we'd get such interoperability (or at least implement the abstract re-frame pattern using these pieces). Chris On Tue, Mar 29, 2016 at 3:40 PM, Luke Horton <[email protected]> wrote: > I see, thanks for that. I guess I was avoiding that strategy initially > because it sort of felt like monkey patching in ruby/js, which is just > bound to break eventually. It's not monkey-patching in this respect, > though, it's just app-specific api design. > > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to a topic in the > Google Groups "ClojureScript" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/qIvYyk5Ptek/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/clojurescript.
