This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-09-09
Channels
- # admin-announcements (1)
- # beginners (78)
- # boot (36)
- # cider (13)
- # cljs-dev (15)
- # cljsjs (3)
- # cljsrn (10)
- # clojure (99)
- # clojure-austin (1)
- # clojure-australia (1)
- # clojure-italy (14)
- # clojure-korea (17)
- # clojure-norway (1)
- # clojure-russia (42)
- # clojure-sg (1)
- # clojure-spec (50)
- # clojure-uk (80)
- # clojurebridge (24)
- # clojurescript (83)
- # community-development (10)
- # conf-proposals (36)
- # core-async (12)
- # cursive (20)
- # datomic (38)
- # hoplon (63)
- # lambdaisland (2)
- # leiningen (6)
- # nyc (2)
- # om (54)
- # om-next (52)
- # onyx (129)
- # planck (15)
- # re-frame (38)
- # reagent (2)
- # rethinkdb (8)
- # specter (1)
- # untangled (2)
I have a question about remotes, when the send method get’s called you get a callback function which you can give the results of a remote call and a query. If I give the query to the callback om.next will stop normalizing these results.. My question is what would be the reason for giving that callback the query instead of nil?
so
(cb res query)
vs
(cb res)
The reason I am playing with this is because I have the following query in my root component:
(query [_]
`[{:companies/autocomplete ~(om/get-query CompanyOption)}
{:contacts/autocomplete ~(om/get-query ContactOption)}
{:confluence/page-linked-companies ~(om/get-query LinkedCompany)}
{:confluence/page-linked-contacts ~(om/get-query LinkedContact)}
{:ui.loading? [:companies/autocomplete :contacts/autocomplete]}])
and all these om/get-query components have the same ident:
(ident [this e]
[:entity/by-id (:db/id e)])
when I do a mutation
(om/transact! this `[(companies.autocomplete/update {:q ~new-term}) :companies/autocomplete]))
normalized data from the other 3 lists will disappear… Am I doing something horribly wrong? Or did I stumble upon a bug and should I make a small case which shows the issue?I have that on true
But no such thing as stupid questions, always start with some seemingly obvious questions it is :normalized
btw
When it happens to me that I lose data like that, it's usually always due to lack of reads and/or lack of indicating re-reads (like with set-query!).
Yes, the initial query will work perfectly.. but when I start updating that is where the trouble starts after each mutation I need to add read for all four query otherwhise data wil dissapear
Ok, don't know how to solve it, I remember having problem with normalized data turning into non-normalized, after some time I just gave up and stayed with un-normalized data for remotes. So Im curious to see if someone else here can help you.
Yeah me too 😅
I fixed it @hlolli The merge-tree function of the reconciler was screwing me over that does a simple merge of the root of the app state, I changed it to
:merge-tree (fn [a b] (if (map? a)
(merge-with merge a b)
b))
now it does not remove idents that are still in use the orignal does
(defn default-merge-tree
[a b]
(if (map? a)
(merge a b)
b))
Lol and this does not fix it now I have to only merge ident maps
maybe the boolean if (map? a) is bit weak and would apply true always, personally I do this in :merge not :merge-tree, but I think it does the same. Maybe match this just to only the keys you want to merge this way?
Yes that will be pretty much the solution
But I find it weird that it calls this on the root app-state
The boolean if (map? a) is indeed always true, I find that a bit of a weird default implementation
yes, the default implementation doesn't cover many cases, an older discussion seems to indicate that there's still some solid logic behind it. But maybe we are doing something "wrong", but I shamelessly change the merge to fit my needs until I find out later better ways.
Yes same here, thnx for listening. So happy I fixed this
Sup dudes, how many of you still using Om Now? Planning to get the whole site into an Om now SPA and then migrate to Om next.
@urbanslug I wouldn't lean on migrating Om Now -> Om Next. There isn't much of a migration path.
(Although if you're still wrangling your site into an SPA and some of it's already Om Now, it might still be a good approach.)
but then today, it's on the factory, and the factory is traditionally "owned" by the same code as the class it's a factory of