Clojurians
# om

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

noonian 00:01:25

I haven’t used them at all really. But I imagine they are most useful when they are used for state that is only relevant to the component like open/closed for an accordion thing. I think the id of a selected component doesn’t work as well because the value of the param is dependent on the shape of the app state (the first item in the list). I think its an anti pattern in react to update local state based on props, and I consider dynamic query params to be a kind of local state.

peeja 00:40:59

Er, I actually meant to say are parameterized properties a reasonable solution. :stuck_out_tongue:

peeja 00:42:18

But yeah, I agree with what you just said. Storing the id of the item the user has clicked in a query param would be appropriate; noticing the first element in the list coming in on the params and setting the query param based on that would be weird.

alberto.portilla 12:42:45

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

alberto.portilla 12:44:47

what function is merging the state? i have 2 candidates, merge-sends #(merge-with into %1 %2)
or
merge default-merge

alberto.portilla 17:36: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

ethangracer 21:29:45

are recursive queries broken for anyone on alpha36?

ethangracer 21:30:44

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

noonian 21:33: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.

anmonteiro 21:34:08

@ethangracer: repro appreciated :slightly_smiling_face:

ethangracer 21:34:59

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

ethangracer 21:35:34

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

noonian 21:35:51

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

ethangracer 21:36:22

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

anmonteiro 21:43:35

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

cmcfarlen 22:00:26

@anmonteiro: it looks like @ethangracer ran into the same bug I did here: https://github.com/omcljs/om/pull/691

cmcfarlen 22:04:05

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

anmonteiro 22:10:37

@cmcfarlen: definitely not the same bug

anmonteiro 22:10:46

sorry for the delay, the patch looks good

anmonteiro 22:11:14

but I haven’t used process-roots extensively

anmonteiro 22:11: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 :slightly_smiling_face:

cmcfarlen 22:13:46

ha, thanks!

cmcfarlen 22:15: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).

cmcfarlen 22:17: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)?

anmonteiro 22:20: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 :slightly_smiling_face:

peeja 22:21:38

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

cmcfarlen 22:31: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.

cmcfarlen 22:32:21

Thanks for looking at that PR though. :slightly_smiling_face:

peeja 23:31:37

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

dnolen 23:43:02

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

peeja 23:44:20

Oh, really?

peeja 23:44:36

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

peeja 23:44:48

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

peeja 23:45:41

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

dnolen 23:50:38

db->tree does lot for you

peeja 23:51:36

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

dnolen 23:51: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

dnolen 23:51:57

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

dnolen 23:52:06

built in normalization is a first class thing

dnolen 23:52:13

we spent a ridiculous amount of time making it work

peeja 23:52:21

I guess I misread something in Slack, then

peeja 23:54: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%2C-Identity-&-Normalization#appendix

dnolen 23:55:26

@peeja: that’s an early tutorial

dnolen 23:55:36

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

peeja 23:56:13

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

peeja 23:57: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?

peeja 23:57:29

Or is it just old?

dnolen 23:57:37

you can do that

dnolen 23:57:41

or use db->tree :slightly_smiling_face:

dnolen 23:57:49

I’m going to keep saying the same thing :smile:

peeja 23:58:07

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

dnolen 23:58:12

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

dnolen 23:58:15

it’s all boring stuff

dnolen 23:58:20

this is why db->tree exists

peeja 23:58:27

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