Also proposed a talk on how we're testing our client-server interactions between o.n and datomic for rapid dev...we'll see if that flies.

@dnolen & @tony.kay: thanks for your all your help.

@tony.kay: I would be interested for sure. I'm going to try and make it this year.

I am also using Datomic on server side (along with Pedestal)...

When delivering props to a child is it okay to create a new hash-map for the purpose? There's a master/detail relationship so the child will be getting the detail props, but also needs the odd thing from the master as well, hence the need to create the hash-map. Note what I'm doing has nothing to do with queries - I'm just hydrating components from devcards at the moment. The item from master that I want to pass down is x. So can I do this in the parent's render:

(for [detail details]
    (child-component-factory {:detail detail :x x}))

(for [detail details]
    (child-component-factory (om/computed detail {:x x})))

@cjmurphy: I'm doing the same in components w/o queries

Using computed just when it semantically makes sense to me

@sander - I waver from one side to the other - at the moment I agree with you - if you want access to some of the parent's prop values use get-computed. If I don't do it the computed way then unfortunately the child's query is going to have parent keys in it - repeating keys that the parent has already seems wrong. The assumption here being that what is taken out of the props is essentially a reflection of the query.

Stumbled across this, http://blog.circleci.com/why-we-use-om-and-why-were-excited-for-om-next/

was posted on HN and /r/clojure

a lot of the usual "I like reagent so why should I change" comments

In the meantime, CircleCI has much funnier series of articles: http://blog.circleci.com/supporting-typed-clojure/ http://blog.circleci.com/why-were-no-longer-using-core-typed/

@danielstockton: ofc why should they change for om.next while it's still in alpha 😄

Hi. If I have at least two levels of components, like this (rendering omitted):

(defui Child static om/IQuery (query [_] [:foo :bar]))
(defui Parent static om/IQuery (query [_] [{:child (om/get-query Child)}]))

Yo it's clojurian, whats up ?

@anmonteiro: how do we redirect programmatically ( routing ) ?

@nxqd: you can use something like this: https://github.com/circleci/frontend/blob/master/src-cljs/frontend/controllers/navigation.cljs#L64-L75

then just use core.async put! to trigger that navigation

example of using it: https://github.com/circleci/frontend/blob/master/src-cljs/frontend/controllers/navigation.cljs#L508

@andrewboltachev: if you leave the Child's query empty then you don't know what properties the Child needs

@anmonteiro: thanks.

@anmonteiro: but that would be me who supplies them ((om/factory Child) ...whatever I need...), right?

right, it's up to you

it depends on your parser as well

but if you're not going to base yourself on queries to know which data to get, then why use them at all?

What about vanilla one?

or by "parser" you mean my read/mutate fns?

yes

but if I have [{:child (om/get-query Child)}], 1st query would be just :child, right?

with nothing about (om/get-query Child)?

yep

or {:child [*]}

so, that's the problem

(though now I see that in one example of remote parser it passed me whole "tree")

As for now this (significantly big) part of Om Next's design looks for me like contradiction. Well, I'll get to it someday. Thanks @anmonteiro

@andrewboltachev: you can save yourself a lot of time by reading up on Relay & Falcor

having the benefit of existing a year before the Om Next they cover the rationale for the design more thoroughly

we just copy it

@dnolen: Got it

Guys please show me good example signature mutate method on server

sample from todomvc not working with om.next alpha-28

oh

all right

@dnolen: wrt. to invariants checking (OM-576), I get it that the best way to go look for compiler options is by using the cljs.analyzer.api then?

@anmonteiro: probably yes

@jdubie: Thanks for om-next-starter, saved me some headaches today as a reference

Question: Is it OK to have only part of your state auto-normalized, or do the algos require everything to be 100% normalized? (I have some stuff in my state that's naturally tree-like, and I'm wondering if I can just leave it in there and still have normalization enabled...)

@drcode: things are only auto-normalized if it finds an Ident implementation for that data, so you can freely store anything you want and opt-in to what gets normalized

@jlongster: Awesome, thanks!

Good day to all! Yesterday we were having a discussion re: tempids and not using a generic :id-key helper that om-next will use to rewrite the original entity in the app state. If you head down this path, is it expected that you will need to do the rewrite of the original entity ID yourself?

yes

@tmorten: There is only one function "hook", so it has to do it all

migrate

@tony.kay: The rewrite will happen in the client so I will need my own migration fn in the reconciler?

In our case, we return a plain map from tid->rid from the server...we don't bother with idents

Are you returning this in the {:value ...} part of the mutation fn?

technically, it comes back from the action thunk (which ends up in :result), and we raise that up to the :tempids key in response

You raise it up in your client code in your migration fn?

no

let me spell out the steps...just a sec

I apologize...

1. The server gets the mutation: parser is invoked. 2. The mutation function is called, and returns an :action thunk 3. The parser invokes the action thunk when it is ready for side-effects 4. The mutation function returns { :tempids { tid real-id } } (we skip om-standard, and use raw ids, not idents here) 5. The parser wraps that result in { mutation-symbol { :result {:tempids ... }}} 6. The server pre-processes that and "raises" the tempids map (so there is no result sub-map) 7. The clients gets that, whcih triggers migrate automatically 8. migrate is the function I showed above

@tony.kay: this is good. Thank you. I see the flow better now. I ended up going back to using standard :db/id in my components and what is strange is that after om.next merges the tempids the om.next/queries map in my app state resets to nil...I'm guessing I have something wired wrong

I'm wondering if it is because my tempid map is inside the {:values {:tempids []} map of my mutation fn

Sounds like your :tempids are a result of when the parser calls the action fn....correct?

right, because side effects go in action, not value

and that returns result

all that is standard with Om

as long as tempids map is in the results of the action thunk, the parser will raise it up for me?

@tony.kay: this is now much clearer for me and I appreciate the help very much

@dnolen: was wondering if we should keep the name invariant for the macro we talked about wrt. OM-576

sounds good to me, not sure what you think

@anmonteiro: works for me

@tony.kay: quick question re: your flow above. I have my tempids being returned from the action thunk but do not see them being "raised" in the response. They are still coming through my 'symbol result map...is this some server side behavior you implemented?

@tmorten: Yes, "the server processes" meant we wrote a function that does the raise

Gotcha. That was the only confusing part for me as I agree that side effects go in the action, however the Om tutorial talks about having :tempids inside the :value key of the mutation fn.

@tmorten: It does say that, because that is where tempids is currently meant to go in Om if you want migrate to work; however, the fact that side effects go in action causes a mis-match. David wants to keep it this way for complete generality, and it is easy enough to make it work...just a bit confusing.