Fork me on GitHub
#om
<
2016-01-22
>
tony.kay00:01:18

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.

tmorten00:01:10

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

tmorten00:01:36

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

tmorten00:01:24

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

cjmurphy04:01:18

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.

sander09:01:43

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

sander09:01:10

Using computed just when it semantically makes sense to me

cjmurphy09:01:24

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

danielstockton10:01:54

was posted on HN and /r/clojure

danielstockton10:01:15

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

yenda10:01:07

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

andrewboltachev12:01:48

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. [])?

Slackbot12:01:48

Yo it's clojurian, whats up ?

jimmy12:01:29

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

anmonteiro13:01:26

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

anmonteiro13:01:35

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

andrewboltachev13:01:48

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

anmonteiro13:01:08

right, it's up to you

anmonteiro13:01:29

it depends on your parser as well

anmonteiro13:01:47

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

andrewboltachev13:01:06

What about vanilla one?

andrewboltachev13:01:28

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

andrewboltachev13:01:44

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

andrewboltachev13:01:59

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

anmonteiro13:01:00

or {:child [*]}

andrewboltachev13:01:37

so, that's the problem

andrewboltachev13:01:45

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

andrewboltachev13:01:59

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

dnolen13:01:37

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

dnolen13:01:08

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

dnolen13:01:11

we just copy it

a.espolov15:01:35

Guys please show me good example signature mutate method on server

a.espolov15:01:59

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

anmonteiro16:01:59

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

drcode18:01:22

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

drcode19:01:52

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

jlongster19:01:15

@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

drcode19:01:47

@jlongster: Awesome, thanks!

tmorten19:01:25

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?

tony.kay19:01:06

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

tmorten19:01:04

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

tony.kay19:01:33

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

tmorten19:01:51

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

tony.kay19:01:32

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

tmorten19:01:22

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

tony.kay19:01:42

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

tmorten19:01:07

I apologize...

tony.kay19:01:29

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

tmorten20:01:44

@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

tmorten20:01:24

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

tmorten20:01:51

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

tony.kay20:01:45

right, because side effects go in action, not value

tony.kay20:01:59

and that returns result

tony.kay20:01:10

all that is standard with Om

tmorten20:01:10

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

tmorten20:01:13

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

anmonteiro20:01:14

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

anmonteiro20:01:32

sounds good to me, not sure what you think

tmorten21:01:24

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

tony.kay21:01:30

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

tmorten21:01:23

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.

tony.kay23:01:10

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