Fork me on GitHub
#om
<
2017-01-18
>
hlolli15:01:03

would love to read an article about the difference between om/full-query om/get-query and how relative queries compose into full queries.

hlolli15:01:26

and om/get-indexer seems like an important function to understand as well there.

hlolli16:01:15

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.

hlolli17:01:50

a simple question, why does [:key '] become [:key ns/] ?

mavbozo17:01:35

a single quote? not a backtick?

jr17:01:37

backtick (syntax-quote) will attempt to fully qualify symbols and will fall back to the current-ns

jr17:01:32

`[:key ~'] is the same as '[:key ]

hlolli17:01:25

no there's no ` in this case, which makes me very surprised by this ns crap coming into my query

anmonteiro18:01:40

@hlolli there has to be a backtick somewhere or it wouldn't get ns-qualified

hlolli18:01:38

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.

hlolli18:01:29

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

tony.kay22:01:47

Is path-meta only used for computing react keys?

tony.kay22:01:18

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?

hlolli23:01:08

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.

tony.kay23:01:39

@hlolli you can override that for sure. We use it to keep Om from touching things like d3 rendering underneath an element

tony.kay23:01:58

but that is update, not initial render

tony.kay23:01:30

the default behavior of it is provided by Om, which is "don't re-render if the data didn't change"

tony.kay23:01:55

so, if that is all you're doing, don't 馃檪

anmonteiro23:01:10

@tony.kay the fact that we use path-meta information to compute React keys is just a nice coincidence

anmonteiro23:01:17

it is actually used to compute incremental renders

anmonteiro23:01:02

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

anmonteiro23:01:09

that's what path-meta tells us

hlolli23:01:24

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.

tony.kay23:01:42

@anmonteiro ah. Yeah, I'm trying to dig in and see why it seems to be so expensive

anmonteiro23:01:56

which Om version are you on?

tony.kay23:01:01

I'm not certain it is the problem, but from what I can tell so far it is my biggest allocator

anmonteiro23:01:11

I can tell you why it's expensive right now, and save you the trouble of digging in 馃檪

anmonteiro23:01:28

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

tony.kay23:01:09

yep, I see that

anmonteiro23:01:20

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

tony.kay23:01:48

from what I'm seeing, this costs a heck of a lot more than some slight inefficiencies in calling react

tony.kay23:01:06

this is the depth order rendering, right?

anmonteiro23:01:08

I've already done a substantial amount of work trying to optimize that function, see https://github.com/omcljs/om/pull/716 for example

tony.kay23:01:48

oh, nvm...I see

anmonteiro23:01:51

it used to walk the entire response regardless of the query, now it only walks properties that match the query

tony.kay23:01:04

yeah, I remember you fixing that

anmonteiro23:01:16

any other ideas you may have for speeding it up are definitely welcome

tony.kay23:01:18

coming back to me

tony.kay23:01:31

So, what's wrong with letting React do the work?

anmonteiro23:01:42

I can see this being a bottleneck in some cases

tony.kay23:01:19

I guess it means you'd have to run the whole UI query for a leaf update

tony.kay23:01:22

which would suck

tony.kay23:01:17

but I'm seeing 3-4 second hiccups on GC

tony.kay23:01:20

which is a lot worse

anmonteiro23:01:23

it's a hard problem, maybe worth profiling in some cases

anmonteiro23:01:36

to see which tradeoff is the less worse 馃槥

tony.kay23:01:41

and by far the biggest allocations always track back to path-meta

anmonteiro23:01:01

do you have a lot of recursive queries?

tony.kay23:01:24

That is the next angle I can look at...possibly lopping off the queries and carrying data around as blobs

tony.kay23:01:30

but that kills some of the elegance of Om

tony.kay23:01:47

thing is, it really isn't that much data

tony.kay23:01:24

and yes on recursive queries

tony.kay23:01:33

does it go better if I hand code those to some depth?

tony.kay23:01:40

and not use '...

tony.kay23:01:27

well, but then I'd have to have separate components for each level of depth 馃槥

anmonteiro23:01:35

I don't think it'd make any difference

tony.kay23:01:51

thought you'd maybe had experience with it though

anmonteiro23:01:05

the problem with recursive queries is that path-meta will walk the entire thing

tony.kay23:01:12

like I said, it isn't a speed problem in execution...memory overhead

tony.kay23:01:47

oh, when you hit ... you don't continue to leverage the specifics of the query?

anmonteiro23:01:48

I wonder if refactoring path-meta to be iterative instead of recursive would maybe fix your issue

tony.kay23:01:03

recursive just blows stack..this is heap for sure

tony.kay23:01:48

I'm stunned, though, cause I really don't understand why it is going through so much memory

tony.kay23:01:32

well, I'll keep exploring and see what I can fix. Thanks for the input

anmonteiro23:01:41

@tony.kay keep me updated. I'd love to make that faster

tony.kay23:01:58

I'm going to try to gather more measurement

tony.kay23:01:02

classify the problems better