Fork me on GitHub
#om-next
<
2016-08-30
>
levitanong11:08:25

Hi all, idiom question: Is it a bad idea to have a read that doesn’t reflect any part of the app-state/schema?

levitanong11:08:45

i.e. if your app state is:

{:school/students []
 :school/address “”}
Is the following an acceptable thing to do?
(defmethod read :student-grades …)

hlolli12:08:51

Not a bad idea, and the read key doesn't have to represent a key in the app state.

levitanong12:08:58

Oh hello again @hlolli! I remember you 😄 Thanks for the advice!

levitanong12:08:52

I have another question though: Is it at all possible to append the result of a remote fetch into a position that isn’t top-level in the app state?

hlolli12:08:07

yes, just add a function to merge. So in the reconciler do: {:state blabla :merge mergefn} and define above (defn mergefn [reconciler state res query] (om/default-merge reconciler state (.. here you put the merge logic from res parameter..) query)))

levitanong12:08:51

oh, this is perfect! thank you 😄

hlolli12:08:46

No problem, I'm still getting the touch for om.next, getting help can be diffucult, so I try my best in situations I can be of any help.

levitanong12:08:48

This makes me want to update the wiki (it seems the documentation is out of date) but there seems to be a hold on it

hlolli12:08:25

yes, the wiki has improved, but its slow. Yes, an article about :merge would be helpful I think. Just all blogs and articles we are willing to take time to write wil generally improve om.next.

levitanong12:08:59

indeed, om.next is one of the most challenging libraries I’ve used to date. 😵

levitanong12:08:22

I’m thinking it would make sense to make mergefn a multimethod that dispatches on query. What do you think?

levitanong12:08:17

(at least, in the case wherein I expect to merge differently a lot)

hlolli12:08:18

Not a bad idea, but that comes to the question of why you don't structure the app state better, are you merging mutations or reads?

levitanong12:08:31

merge reads.

levitanong12:08:07

as for why I don’t structure the app better, I guess it’s a lack of experience 😛

hlolli12:08:11

no, actually, even with good structured data I think doing dispatch on merge is not that bad idea.

hlolli12:08:43

but the idea of thinking with links and using normalized data, vectors instead of maps, may be good to get used to, so nested data wont be a problem. But I mostly use denormalized data like a beginner so I can't say much.

levitanong12:08:56

Yeah, a lot to study. Thanks, friend! 🍺

hlolli12:08:54

no problem, best of luck with the battle 🙂

levitanong12:08:38

What’s the difference between merge, merge-tree and merge-ident? 😮

hlolli12:08:27

merge is clojure.core fn, merge! is om.next fn, I believe the latter two are just internal library functions, when you use idents or read, there's probably some merge-ing going on under the hood. I assume you understand this (clojure.core/merge {:a {:b 1 :c 2} :d 3} {:a {:b 6 }}) => {:a {:b 6} :d 3}, if so, then you understand what merge is doing.

levitanong13:08:23

ah, sorry, i meant the reconciler configs

levitanong13:08:42

these are a lot of configs 😛

hlolli13:08:09

didnt know this existed, interesting

levitanong13:08:45

Indeed! Anyway, gtg! later man.

levitanong17:08:28

@hlolli It looks like the correct config to set is the :merge-tree, because it is the function that is used for mutating the state. :merge eventually calls :merge-tree to do its job.

hlolli18:08:46

ok, I will check it out, but I did function for :merge today and it behaved just like I wanted it. Also a remainder for me to read the sources more touroughly. @levitanong please post if you discover something, kind of dead channel here. (of course more activity on #om).