Fork me on GitHub

@not-much-io the argument against this sort of thing ...

(re-frame/subscribe [:simple-sub :x])  ; sub to :x
(re-frame/subscribe [:simple-sub :y])  ; sub to :y
is that you are pushing information about the structure into your views. They now contain a path. They now "know" about the structure of app-db. When, at a later time, you change that structure in app-db (and you will!) then you'll be grepp-ing through your view code trying to find all paths that match and modifying them.


On the other hand it is convenient.


So it is a trade off. And the true answer inevitably starts with "Well, it depends ...".


I personally resist the urge to create "accessor style" subscriptions. But, on the other hand, I tend to be very vocally against premature abstraction.


You know the distinction between semantic markup (e.g., <button>, <div class=“warning”>) vs presentational markup (e.g., <div class=“bold red”>)? I think of subscriptions the same way: we prefer subscriptions to be “semantic” rather than “presentational”. I don’t think that’s premature abstraction at all.


Along those lines… if the view should be as dumb and semantic as possible, then suggests that handlers should accept as few parameters as possible, right? Since a handler will have access to all of app-db, the view should give it as little as it needs, and make the handler do all the legwork of getting other things. The alternative is to try and make handlers "pure" from the view's perspective, where the view tries to give the handler as many things as possible.


There's no problem with the view providing all the info necessary (the parameters of the query), and for the handler to know howto make that query happen, but it *IS* a problem if the view knows where the data is coming from within app-db. We want the subscription to be a declarative statement about what the view's needs, with the actual implementation of that query hidden.


@mikethompson: is re-com already compatible with reagent 0.6.0?


@mikethompson: these kind of subscriptions are allowing us go from a denormalized app-db to a normalized one.


also, our views have many forms that depend on this now normalized data. we created subscriptions to get data (like :company->positions) that give us a ratom of this data. initially this data is on the server. we start a request from the subscription (as you proposed at Subscribing to a Database) and later update the app-db with normalized data from this request.


we also made some subscriptions and handlers to control form editing states. they are transparently added to the app-db so that it is easy to serialize and persist


the view just knows that it wants a space to hold editing state and some handlers to manipulate it


we already changed the structure of editing state data 3 times without ever needing to touch our views


Is there a typo here or am I doing something wrong? :on-mouse-out (handler-fn (reset! over-atom false)) Link: It doesn't work for me like that, I'm getting: Invariant Violation: Expected onClick listener to be a function, instead got type object. :on-mouse-out #(handler-fn (reset! over-atom false)) Does work.


My actual code: :on-click #(utils/handler-fn (swap! should-scroll not))


Scratch that, after figwheel auto reload, the #(..) one also start failing: wrong number of args(1) passed


nvm. I realized I'm using a usual :require for a macro, without :include-macros


We decided to specialize our console component on for re-frame and this is the result:


@mikethompson sry, I didn't notice your message to me. Yeah your argument makes sense. The only part I would see a undeniable use case for what I suggested is truly just: 1) If you have lots of "first level" values in app-db AND 2) Your app is getting ready (the location in app-db unlikely to change) Very situational, not something to suggest to beginners right away. I'll close the issue and add the arguments against it you brought out as a comment.