Fork me on GitHub
#om
<
2015-12-13
>
jannis02:12:57

Mmmh, memoizing db->tree reduces query times by about 50%.

naomarik06:12:51

haha @jannis this is where i'm at right now 馃槈

naomarik06:12:10

except add all the popular clojure libs and functional programming terminology

naomarik06:12:38

i'm having fun 馃槂

anisoptera09:12:37

is the chrome debug environment expected to work with om.next + natal?

anisoptera09:12:56

maybe this is better suited for #C0E1SN0NM but

anisoptera09:12:00

trying to do some simple nesting of test components and just failing hard

anisoptera09:12:10

and the lack of any debug messages is killing me

anisoptera10:12:15

i solved my immediate problem, at least, and i鈥檓 really liking the high level design

si1415:12:00

wow, this particular piece is tricky

si1415:12:01

(defn get-people [state key] (let [st @state] (into [] (map #(get-in st %)) (get st key))))

si1415:12:49

feels a bit like leaky abstraction

anmonteiro15:12:11

@si14: that's probably outdated

anmonteiro15:12:18

you can use db->tree now

si1415:12:31

@anmonteiro: can you please provide an example?

anmonteiro15:12:30

(defn read
  [{:keys [query state] :as env} k _]
    (let [st @state]
      {:value (om/db->tree query (get st k) st)}))

si1415:12:32

and a more general question: is it even worthwhile to invest time into om.next now with intention to build back-office (but production) stuff, or is it too early and I would be better off taking Reagent and hacking together something fast?

si1415:12:22

I understand that the question might be offensive, sorry about that, just really wondering about opinions of more experienced people simple_smile

anmonteiro15:12:42

answering your question, it's not offensive at all. I'd say you wanna use Om Next if you find it tackles the problems you're trying to solve

anmonteiro15:12:17

really depends on your use case. If you feel Reagent is better suited for your problem domain, go ahead and use it

si1415:12:30

the problem is, I'm not really sure that my feelings are adequate here. Om Next is a bit overwhelming, but I see the intensions behind it and it seems very reasonable; on the other hand it would be a shame if e.g. API will change significantly between now and beta

si1415:12:20

on the other hand, I already know Reagent, it's very simple (at surface, that is), but it will probably not scale well for complex apps with interesting server-side story

anmonteiro15:12:53

I don't know the inner workings of Reagent so I can't provide an opinion on that

anmonteiro15:12:17

what I can say is Om's API is unlikely to change significantly

anmonteiro15:12:00

David has been very careful wrt. API changes

si1415:12:46

yeah, thank you. tough decision to make simple_smile

si1415:12:07

is there any example of remote mutations out there? It seems that it is missing from the guide

anmonteiro15:12:45

actually, that's also not done yet

si1416:12:44

thank you, again

anmonteiro20:12:14

@dnolen: will you accept a PR adding dispatch to om.next.server?

jannis20:12:10

@anmonteiro: I second that PR. I noticed that it was missing but forgot to do something about it. simple_smile

anmonteiro20:12:36

it is a convenience, but one that also exists for the client side, so why not on the server?

jannis20:12:04

Yeah, only a small piece of the puzzle but it's slightly confusing because you'd expect it to be there on both sides.