Fork me on GitHub
#om
<
2016-06-09
>
alberto.portilla09:06:45

Hello, i have one question about the callback on the remote part of the reconciler

alberto.portilla09:06:47

what function is merging the state? i have 2 candidates,

merge-sends  #(merge-with into %1 %2)
or
merge        default-merge

alberto.portilla14:06:24

to be more specific, my remote returns an empty key like

:key []
but after passing it throught the callback to merge it, the key dissapears

ethangracer18:06:45

are recursive queries broken for anyone on alpha36?

ethangracer18:06:44

my app crashes on add-root! when I uncomment the lines in my queries with recursive joins

noonian18:06:43

I ran into issues with my recursive queries + unions because of a combination of this issue: https://github.com/omcljs/om/issues/604 and when components get re-rendered due to a transact! it was receiving the result of the root query and not the query rooted at the union. It didn’t cause any crashes, just weird rendering behavior.

anmonteiro18:06:08

@ethangracer: repro appreciated 🙂

ethangracer18:06:59

@noonian: yeah I’ve had that too, everything in my db is normalized though

ethangracer18:06:34

@anmonteiro: will do, wanted to see if anyone else had run into it, if I was missing something already known

noonian18:06:51

Does it work for initial render and then break when something transacts or merges in a server response?

ethangracer18:06:22

no, the crash happens before the initial render… let me get the stack trace

anmonteiro18:06:35

@ethangracer: sounds like a bug, I’ll be able to tell more with a minimal repro, thanks

cmcfarlen19:06:05

Oh, sorry, it might not be the same. I got a little excited there

anmonteiro19:06:37

@cmcfarlen: definitely not the same bug

anmonteiro19:06:46

sorry for the delay, the patch looks good

anmonteiro19:06:14

but I haven’t used process-roots extensively

anmonteiro19:06:37

I actually haven’t really felt the need to use it, so if it solves your problem and doesn’t break the tests, should be good 🙂

cmcfarlen19:06:22

I know I've seen a similar stack trace when building indexes related to recursive queries though. I think I had two recursive joins in one query (for a graph).

cmcfarlen19:06:40

I have been steering away from using process-roots too, but now my root query is getting pretty busy. How are you reconciling remote reads when nested components need new info (say from a lazy loaded list of options)?

anmonteiro19:06:03

@cmcfarlen: not sure I understand the question, but the AST is just much more powerful than what it might look like at the beginning 🙂

peeja19:06:38

The :value returned by a mutate function is ignored, right? Why is it even there/documented?

cmcfarlen19:06:27

@anmonteiro: I'm certain I didn't explain it well. I'm also certain I need to go back through my parser code with a fresh perspective. I wrote it initially months ago and tried to make a general reader that accepts hints from the query parameters (to say, delay a remote read or elide a level of state for :query-root). Its pretty nice for some situations, but more and more I am finding myself trying to sidestep that stuff which tells me its getting crusty.

cmcfarlen19:06:21

Thanks for looking at that PR though. 🙂

peeja20:06:37

Is there any documentation on when/how to recursively call the parser?

dnolen20:06:02

not really, but don’t do it if you can avoid it

peeja20:06:20

Oh, really?

peeja20:06:36

I guess I don't have a good sense of what an Om Next app is supposed to look like at scale

peeja20:06:48

It seems like it requires a lot of custom fiddling for each and every key

peeja20:06:41

Like, should I be manually resolving links in my read for every key that can have idents it its value(s)?

dnolen20:06:38

db->tree does lot for you

peeja20:06:36

Oh, hmm. I've been avoiding Om's built in normalization; I thought it was only designed for getting started.

dnolen20:06:39

server side it can be a bit more work of course depending on what db you’re using - but it’s not going to be any worse than GraphQL or Relay

dnolen20:06:57

@peeja ok, that’s strange that you think that

dnolen20:06:06

built in normalization is a first class thing

dnolen20:06:13

we spent a ridiculous amount of time making it work

peeja20:06:21

I guess I misread something in Slack, then

peeja20:06:51

@dnolen: So the idea is that it's correct to do something like the (into [] (map #(get-in st %)) (get st key)) in get-people because normalization ensures that the map you get will only have keys that were in Person's query? https://github.com/omcljs/om/wiki/Components,-Identity-&amp;-Normalization#appendix

dnolen20:06:26

@peeja: that’s an early tutorial

dnolen20:06:36

you don’t even need to bother with that with db->tree

peeja20:06:13

I feel like I'm like three steps removed from asking the correct question here 🙂

peeja20:06:23

I see a lot of example code do things like (into [] (map #(get-in st %)) (get st key)) in their reads to dereference links. Is that recommended, or is that just a shortcut for small tutorials?

peeja20:06:29

Or is it just old?

dnolen20:06:37

you can do that

dnolen20:06:41

or use db->tree 🙂

dnolen20:06:49

I’m going to keep saying the same thing 😄

peeja20:06:07

Oh, I see, I'm misunderstanding how I'm supposed to use db->tree 🙂

dnolen20:06:12

the point is writing manual recursive parsing code etc. is a huge pain in the butt

dnolen20:06:15

it’s all boring stuff

dnolen20:06:20

this is why db->tree exists

peeja20:06:27

I just needed you to say it a few more times, apparently. 😛

ethangracer21:06:58

@anmonteiro: repro for the issue I discussed earlier here: https://github.com/egracer/union-recursion-bug Line 15 in app.ui is commented out to avoid the crash on initial render. uncommenting causes the crash. switching to om-35 with the same line uncommented does not crash.

peeja21:06:34

@dnolen: Thanks for being patient with me! I get it now. 🙂 Works like a charm (of course).

peeja21:06:03

Is there a preferred way to map queries to several REST endpoints? The two strategies that come to mind are either a separate remote for each endpoint (which sounds like it could become a lot of remotes) or a single remote that picks things apart in the send (which sounds difficult). Is one considered better than the other?

anmonteiro21:06:56

@peeja: I’d go for multiple remotes

peeja21:06:13

Awesome, thanks.

anmonteiro21:06:23

it would just look better overall

anmonteiro21:06:30

you could do nice dispatching on them

anmonteiro21:06:36

e.g. multimethods, core.match

anmonteiro21:06:44

(inside the send function)

peeja21:06:28

Yeah, I think a multimethod is what I'm going to go with.

ethangracer21:06:47

also @anmonteiro I can file an issue if that helps, looks like it only happens for recursion nested in a union

anmonteiro21:06:21

@ethangracer: sorry I’m not going to look at that

anmonteiro21:06:42

please make a minimal repro. Including untangled is most definitely not minimal

anmonteiro21:06:31

also should be runnable without a server

ethangracer21:06:50

@anmonteiro: k, wanted to do the best to reproduce the issue as I encountered it but will strip out untangled and let you know when it’s done — doesn’t currently use the server but i’ll get rid of those pieces too

anmonteiro21:06:40

@ethangracer: nothing against untangled. I’d just prefer to look at something bare

anmonteiro21:06:49

takes me less time, as you could imagine

ethangracer22:06:05

yup, no worries

madstap22:06:43

(map first (filter (fn [[_ x]] (odd? x)) (map-indexed vector '(1 2 3 4 5)))) 4

madstap22:06:26

Sorry, I cleaned something off my keyboard

ethangracer23:06:53

@anmonteiro: ok removed all the non-essential stuff. I can’t get it to reproduce with less, 5 simple components and om setup, all in app.core. hope that makes it easier. the commented recursive query is the culprit: https://github.com/egracer/union-recursion-bug/blob/master/src/app/core.cljs#L14

anmonteiro23:06:15

@ethangracer: looks great, thanks

anmonteiro23:06:27

I’ll take a look at it tomorrow

ethangracer23:06:26

sounds good, thanks!