Fork me on GitHub

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}))
Or do I need to do this instead:
(for [detail details]
    (child-component-factory (om/computed detail {:x x})))
The former way - creating a hash-map, makes a lot more sense to me. Just not seen an example of doing it that way yet.


@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.


was posted on HN and /r/clojure


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


@danielstockton: ofc why should they change for 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)}]))
Would [:foo :bar] matter? Or would my code be equivalent if I just leave child's query empty (e.g. [])?


Yo it's clojurian, whats up ?


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


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


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


@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?


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


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


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


Guys please show me good example signature mutate method on server


sample from todomvc not working with alpha-28


@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?


@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?


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


@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?


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 merges the tempids the 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


@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 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.