Fork me on GitHub
#om
<
2016-12-05
>
haywood00:12:36

the response object is basically a partial version of the app-state, that includes new entries into om.tables

haywood00:12:41

I don't know if that makes a difference

haywood01:12:14

I've made progress by not managing normalization myself, and relegating it to the default-merge function. but I don't know why it would be different since we're doing the same thing

anmonteiro01:12:51

@haywood perhaps because if you do it yourself, the default-merge would do it again?

anmonteiro01:12:58

leading to unexpected results

haywood01:12:10

yea, but it seems like when normalize is set to false, it wouldn't do it again

anmonteiro01:12:19

that's right

anmonteiro01:12:55

perhaps it's just a matter of passing the query you wish to normalize against to the callback of send

haywood01:12:56

it was creating links correctly, but the key in the table map would be nil

haywood01:12:00

if you've ever seen that

haywood01:12:16

actually, the value in the link was nil too

haywood01:12:26

yea that's what I ended up doing

haywood01:12:32

and it's handling it correctly 馃檪

haywood04:12:06

anyone run into the issue where the default merge is overwriting the om.next tables? my data coming in introduces a new record into the table, but after the merge it's the only one in app-state

haywood04:12:57

looks like it's just a symptom of the shallow merge

ianchow06:12:42

@haywood try having a look at the source of untangled.client.core鈥檚 merge-state! function which utilizes om鈥檚 default-merge at the end. they add a new top level key for the query so the default-merge doesn鈥檛 pollute the database root, and other things i couldn鈥檛 wrap my head around.

haywood14:12:44

haha ok, I will. thanks @ianchow