This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-18
Channels
- # bangalore-clj (1)
- # beginners (60)
- # boot (98)
- # cider (8)
- # clojure (158)
- # clojure-dusseldorf (16)
- # clojure-france (3)
- # clojure-hamburg (2)
- # clojure-mke (2)
- # clojure-russia (11)
- # clojure-serbia (1)
- # clojure-spec (123)
- # clojure-uk (59)
- # clojurescript (44)
- # code-reviews (16)
- # community-development (51)
- # core-async (46)
- # cryogen (1)
- # cursive (9)
- # datascript (5)
- # datomic (36)
- # emacs (3)
- # events (12)
- # hoplon (57)
- # jobs (1)
- # juxt (3)
- # klipse (55)
- # lein-figwheel (3)
- # leiningen (5)
- # luminus (3)
- # off-topic (8)
- # om (75)
- # om-next (9)
- # onyx (17)
- # pedestal (7)
- # portland-or (3)
- # proton (36)
- # protorepl (6)
- # re-frame (3)
- # reagent (33)
- # remote-jobs (1)
- # ring (23)
- # ring-swagger (2)
- # rum (1)
- # specter (1)
- # untangled (36)
- # yada (11)
would love to read an article about the difference between om/full-query
om/get-query
and how relative queries compose into full queries.
whatever is happening then om/set-query! is really annoying me, I run it and the parser is not called and when I do anything that triggers the component to update its local state then the parser will run with a query that belonged to the component when it first rendered. As if it's some sort of zombie component.
backtick (syntax-quote) will attempt to fully qualify symbols and will fall back to the current-ns
no there's no ` in this case, which makes me very surprised by this ns crap coming into my query
@hlolli there has to be a backtick somewhere or it wouldn't get ns-qualified
yes, the spirit of the rubber duck hit me when I was going to prove that statement wrong (of corse 100% correct what you say). there is a set-query that was lurkins inside one of my component that had backtick.
and @jr using ~'_ within a backquote expression does the trick, I've seen this in om-next code in the wild but never undserstood the need for this until now
So, I'm seeing a lot of GC overhead in my Om app, and a lot of it seems to be coming from path-meta
. Wondering why we need a generated react key on the factories. Is this part of sside rendering?
trying shouldComponentUpdate for the first time, does any om user use it, or does the reconciler overwrite it, I seem to update the component despite returning false, base that false on the properties passed from parent.
@hlolli you can override that for sure. We use it to keep Om from touching things like d3 rendering underneath an element
the default behavior of it is provided by Om, which is "don't re-render if the data didn't change"
@tony.kay the fact that we use path-meta
information to compute React keys is just a nice coincidence
it is actually used to compute incremental renders
as in, if a component calls transact!
, you want to know what's its path in the tree so that we only re-render the subtree for which that component is the root
that's what path-meta
tells us
yes Im hoping to get rid of all the nils popping up in componentWillUpdate and componentDidUpdate when comparing next and previous props. But the fact that Im getting nils makes me wonder about if im doing something fundementally wrong. Why Im constatly getting different property values and component path errors, which have been bothering me ever since I started doing om.next.
@anmonteiro ah. Yeah, I'm trying to dig in and see why it seems to be so expensive
which Om version are you on?
I'm not certain it is the problem, but from what I can tell so far it is my biggest allocator
I can tell you why it's expensive right now, and save you the trouble of digging in 馃檪
so what it does is deep walk your parser's response and annotate every data structure with metadata which is the path of that structure in the response tree
the allocations you're seeing are the metadata object creations, and the (possibly large) amount of time spent in the function is because it deep walks the response
from what I'm seeing, this costs a heck of a lot more than some slight inefficiencies in calling react
I've already done a substantial amount of work trying to optimize that function, see https://github.com/omcljs/om/pull/716 for example
it used to walk the entire response regardless of the query, now it only walks properties that match the query
any other ideas you may have for speeding it up are definitely welcome
I can see this being a bottleneck in some cases
exactly
it's a hard problem, maybe worth profiling in some cases
to see which tradeoff is the less worse 馃槥
do you have a lot of recursive queries?
That is the next angle I can look at...possibly lopping off the queries and carrying data around as blobs
I don't think it'd make any difference
the problem with recursive queries is that path-meta
will walk the entire thing
ah right
I wonder if refactoring path-meta
to be iterative instead of recursive would maybe fix your issue
gotcha
I'm stunned, though, cause I really don't understand why it is going through so much memory
@tony.kay keep me updated. I'd love to make that faster