This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (1)
- # aws (3)
- # beginners (52)
- # boot (150)
- # braid-chat (1)
- # braveandtrue (5)
- # bristol-clojurians (2)
- # cider (21)
- # cljs-dev (1)
- # cljsfiddle (1)
- # cljsjs (5)
- # cljsrn (4)
- # clojars (3)
- # clojure (236)
- # clojure-berlin (2)
- # clojure-czech (1)
- # clojure-madison (1)
- # clojure-russia (164)
- # clojure-sdn (1)
- # clojure-sg (2)
- # clojure-uk (64)
- # clojurescript (149)
- # core-async (31)
- # cursive (33)
- # datomic (2)
- # devcards (5)
- # funcool (3)
- # hoplon (142)
- # immutant (27)
- # juxt (7)
- # lein-figwheel (6)
- # liberator (6)
- # off-topic (4)
- # om (46)
- # onyx (26)
- # parinfer (5)
- # perun (56)
- # proton (6)
- # re-frame (19)
- # reagent (1)
- # remote-jobs (12)
- # ring-swagger (17)
- # slack-help (2)
- # spacemacs (11)
- # specter (1)
- # untangled (11)
- # yada (3)
@not-much-io the argument against this sort of thing ...
is that you are pushing information about the structure into your views. They now contain a path. They now "know" about the structure of
(re-frame/subscribe [:simple-sub :x]) ; sub to :x (re-frame/subscribe [:simple-sub :y]) ; sub to :y
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.
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.,
<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: 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))
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))
Scratch that, after figwheel auto reload, the #(..) one also start failing: wrong number of args(1) passed
@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.