This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-05
Channels
- # adventofcode (41)
- # bangalore-clj (4)
- # beginners (283)
- # boot (62)
- # clara (9)
- # cljsrn (3)
- # clojure (112)
- # clojure-brasil (1)
- # clojure-greece (1)
- # clojure-korea (6)
- # clojure-russia (99)
- # clojure-spec (29)
- # clojure-uk (12)
- # clojurescript (34)
- # clojurex (5)
- # core-logic (1)
- # cursive (31)
- # datomic (30)
- # devcards (5)
- # editors (19)
- # emacs (31)
- # events (5)
- # garden (4)
- # hoplon (137)
- # lein-figwheel (3)
- # luminus (4)
- # mount (7)
- # off-topic (7)
- # om (18)
- # om-next (3)
- # onyx (88)
- # proton (1)
- # protorepl (6)
- # re-frame (48)
- # reagent (15)
- # spacemacs (41)
- # testing (1)
- # untangled (2)
- # yada (18)
the response object is basically a partial version of the app-state, that includes new entries into om.tables
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
@haywood perhaps because if you do it yourself, the default-merge
would do it again?
leading to unexpected results
that's right
perhaps it's just a matter of passing the query you wish to normalize against to the callback of send
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