Fork me on GitHub
#om
<
2016-09-09
>
mitchelkuijpers11:09:20

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?

mitchelkuijpers11:09:51

so

(cb res query)
vs
(cb res)

mitchelkuijpers11:09:59

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?

hlolli11:09:33

maybe a stupid question, did you try to set :normalized? true in the reconciler?

mitchelkuijpers11:09:40

I have that on true

mitchelkuijpers11:09:30

But no such thing as stupid questions, always start with some seemingly obvious questions it is :normalized btw

hlolli11:09:07

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!).

hlolli11:09:50

Do you get the data into the global-state atom/reconciler state?

mitchelkuijpers11:09:40

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

hlolli11:09:32

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.

mitchelkuijpers11:09:14

Yeah me too 😅

mitchelkuijpers12:09:56

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))

mitchelkuijpers12:09:20

Lol and this does not fix it now I have to only merge ident maps

hlolli13:09:01

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?

mitchelkuijpers13:09:38

Yes that will be pretty much the solution

mitchelkuijpers13:09:57

But I find it weird that it calls this on the root app-state

mitchelkuijpers13:09:01

The boolean if (map? a) is indeed always true, I find that a bit of a weird default implementation

hlolli13:09:26

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.

mitchelkuijpers13:09:24

Yes same here, thnx for listening. So happy I fixed this

urbanslug16:09:40

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.

urbanslug16:09:07

I hope that’s a good approach. Convert dommy stuff to Om now then to Om next

urbanslug16:09:17

Since a lot is already in Om now.

peeja17:09:34

@urbanslug I wouldn't lean on migrating Om Now -> Om Next. There isn't much of a migration path.

peeja17:09:40

It's essentially a rewrite.

peeja17:09:19

(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.)

urbanslug17:09:25

@peeja An entire rewrite? Have you done it?

urbanslug17:09:33

Like a rewrite for tests too?

peeja17:09:54

If they're testing your components directly, likely.

urbanslug17:09:54

Because tests OMG

peeja17:09:25

Think of Om Next as a completely different library, built by the same people.

urbanslug17:09:16

@peeja have you seen a much of a performance or productivity boost from Om Next?

peeja17:09:29

I'm still working on the migration. 🙂

urbanslug17:09:40

I saw a Nolen talk. He was talking about property based testing.

urbanslug17:09:51

I’ve used quickcheck on haskell. It’s really cool.

peeja17:09:05

Yeah, I'm looking forward to being able to do that

jasonjckn21:09:03

componentDidUpdate is not firing on my union subcomponents

jasonjckn21:09:48

hm I see, my subcomponent is always being remounted

peeja21:09:07

What's 1.0.0-alpha44, if the project.clj on master says 1.0.0-alpha43?

peeja21:09:27

Oh, looks like that commit is tagged 1.0.0-alpha43 and 1.0.0-alpha44. Fatfingered?

jasonjckn21:09:57

why isn't the react key fn an om.next interface like everything else

jasonjckn21:09:21

om/ReactKey (react-key [T props] (:id props))

jasonjckn21:09:35

instead of om/factory :key :id

jasonjckn21:09:56

most of the time the keyfn is the ident too

peeja21:09:41

I'd say because the child's key is the parent's responsibility, not the child's

jasonjckn21:09:47

nods good pt

peeja21:09:12

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

peeja21:09:37

("traditionally", as if this library were decades old) 🙂

jasonjckn21:09:58

90% of the time the ident would work as the react -key

peeja21:09:31

I actually find keeping the factory with the class feels weird to me, but I haven't dug in enough to feel comfortable claiming it's the wrong pattern

peeja21:09:47

Yeah, the ident seems like a reasonable default, at least