This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-30
Channels
- # announcements (2)
- # avi (12)
- # aws (6)
- # beginners (49)
- # boot (140)
- # cider (2)
- # cljs-dev (5)
- # cljsrn (9)
- # clojure (149)
- # clojure-czech (6)
- # clojure-miami (1)
- # clojure-nl (2)
- # clojure-russia (19)
- # clojure-ukraine (1)
- # clojurescript (34)
- # conf-proposals (36)
- # core-async (2)
- # cursive (11)
- # emacs (2)
- # funcool (23)
- # hoplon (2)
- # incanter (4)
- # jobs (1)
- # ldnclj (19)
- # om (47)
- # onyx (5)
- # proton (12)
- # re-frame (20)
- # ring-swagger (17)
- # testing (1)
are there any trade-offs in relying on life-cycle methods? how often do you guys use them?
test.repl=> (om/db->tree '[:items] {:items [{:foo 1} {:foo 2}]} {})
{:items [{:foo 1} {:foo 2}]}
test.repl=> (om/db->tree '[{:items [:foo]}] {:items [{:foo 1} {:foo 2}]} {})
{:items [{} {}]}
also
test.repl=> (om/db->tree '[{:items [*]}] {:items [{:foo 1} {:foo 2}]} {})
{:items [nil nil]}
@jlongster well, 3rd params is refs
, i.e. which is used for denormalizing
it should be like
{:item/by-id {1 ... 2 ... 3 ...}}
well AFAIK db->tree
is for denormalizing
not for querying
it runs the query and follows idents, basically. without idents, it still runs the query
well, I were once doing sth like this
and Antonio Monteiro asked me "why you passing already denormalized tree?"
yep in the end it will be normalized, but this caught my eye. if you can't sub-select normal maps, that's fine but seems like it should work. Might be wrong though. (only part of your query might be selecting normalized data)
I've went through the code (of db->tree
, and denormalize*
) but I still can't undertand all functionality of that fn
it could be called "run-query" basically, but db->tree
is better. no time to understand it either myself right now, easier to ask here (will look tomorrow tho)
fact seems to be that there's no such thing as run-query
, and you always have to do it yourself
it's also seems to be strange for me
yeah, you have to guide it. which is why I think db->tree
is better because run-query
would give false impressions. but basically, I see no reason why my examples shouldn't work. will figure it out tomorrow, getting late here
@andrewboltachev: @jlongster My understanding is that to run a query you call your own parser with the query you want to execute, and it works on the normalized state and uses the read functions you have defined.
So for instance in the state I have some 'top level' things that don't have ids. And I can query their value with this function:
(defn query [kw]
(let [res (my-parser {:state my-reconciler} `[[~kw _]])]
(when (not-empty res) (apply val res))))
I'm calling them my-parser
and my-reconciler
so as not to confuse them with om/parser
and om/reconciler
which created them in the first place.
Is there any reason why the React lifecycle methods don't print to the console?
(defui MenuItem
static om/Ident
(ident [_ {:keys [id]}]
[:navbar/items-by-id id])
static om/IQuery
(query [_]
[:name])
Object
(componentWillUpdate [this next-props next-state]
(println "willReceiveProps"))
(componentDidUpdate [this prev-props prev-state]
(println "did update"))
(render [this]
(let [{:keys [name]} (om/props this)]
(dom/li #js {:className "pure-menu-item"
:key name}
(dom/a #js {:className "pure-menu-link"}
name)))))
hmm nevermind, seems to work now
I have a Root component which contains a LoginForm. When I make a change in the local state of LoginForm, the parser is called with a key belonging to the root's query. Should such a thing happen?( I might have messed up my parser or something.)
@tawus: not completly, no. But instead I have a workaround which prevents the Root rendering to override the updated query params.
still triggering a Root rendering though. not a big deal in my particular case, because the component with the dynamic queries is a child of the Root and there isn't much overhead of re-rendering everything.
also just let me know if you have any question about what I did with sub-query
(although I will only have access to the actual code again on Monday to look up details if needed)
In my case I was following https://github.com/jdubie/om-next-router-example/blob/master/src/om_router/core.cljs example and once I tried to put a form inside a tab, it started acting strange. I think it has to do with union queries but I am not sure. I'll keep updating.
Well I could reproduce my Root rendering issues, even without any routing. Also, I was using only (nested) joins, no unions
I've got a query like [ {:overview/panels [:title :body [:overview/count _]]}]
,gets send to a remote.
Does someone has any ideas on how I could parse the [:overview/count _]
(thinking with links-style) out of the query on the server?