I'm using a link in a query, like [:foo :bar [:link-item _]], and if I transact! on that component the link-item is nil from props. Anyone else seen that?

I am using https://github.com/anmonteiro/aemette as a lein template. My read calls for queries in the sub-components don’t invoke send when I return {:remote true}. What am I missing here ?

@tawus: Are you saying :some/key is a child of :dom-com/props? I can't tell from your snippet. If that is the case, :dom-com/props will need to set the :remote to a value somehow, as well, in order for the child's value to be sent to the remote.

@drcode: Yes, that is the case. Hmm...

@tawus: You need to do something like this:

(defmethod read :dom-com/props
           [{:keys [parser query target ast] :as env} _ _]
           (if target
               {:target (assoc ast :query (parser env query target))}
               {:value (parser env query)}))

@tawus: See also recurse-remote in https://github.com/awkay/om-tutorial/blob/master/src/main/om_tutorial/parsing.cljs

Still doesn’t work but if I return {:remote true} it does invoke send.

You have to add :query-root true to the ast if that is a subquery, or not a top level key

@taylor.sando: Do I have to that while returning from the :dom-com/props (query) or :some/key (sub-query). I tried the latter but it didn’t work

{:remote (assoc ast :query-root true)} This is what my subquery is returning.

Which one do you want sent to the server?

the subquery

The :dom-com/props that drcode suggested would be fine, you need to make sure some/key has a :target (assoc ast :query-root true)

Thanks, @drcode & @taylor.sando. It was a typo on my end.

It is working now.

@taylor.sando: Any good documentation anywhere on the meaning of :query-root?

Not really beyond looking at code examples from different projects and reading the source code. I doubt the documentation will get better until the Beta is released.

I was using :query-root but I was missing the condition based on target. I think reading all the messages in this group is the only way forward for now

You can also read the archives here: http://clojurians-log.mantike.pro/om/index.html

The Om Next query language definition refers to EdnVector, EdnValue etc. Is there a definition of what an EdnValue is anywhere?

@jannis: not sure there is, but I'd say a value is: number, string, nil, keyword, boolean or symbol

hope I'm not forgetting anything

@anmonteiro: Yeah, the EDN spec itself is "casual", leaving this up to interpretation

I guess a vector of values may again be a value by itself

Same for other "composed" values

@jannis: You might be right, yes

since you can have, say vectors, as the key of a map

Hi! I posted this on #C03S1L9DN and was pointed here - didn’t realise #C06DT2YSY had it’s own channel.

I’m trying to get my head around normalization and thought I was making progress, but I’ve stumbled again and am not sure if I’m just not thinking correctly about the problem. How do I normalize the current user’s messages? See this gist for the details: https://gist.github.com/addywaddy/2b2ecf4ca389afb0d202

Is there anyone who's doing optimistic updates with om.next, datascript and datomic? Here's my imperfect approach and questions: https://gist.github.com/petterik/50779d8cf15d6b6443e4 Let me know, or comment on the gist, if you have answers, feedback or questions

@petterik: I am, using tempids, but not reverting in case of an error, not sure how that part is handled

@petterik: I think what I could do is in the send function if the result is an error and the request contains tempids then I can call some function that will remove that tempid from the tree? not sure if there's a best practice for that or a standard way

How are you using tempids though? I might be missing something basic here

transact with a tempid here: https://github.com/marianoguerra-atik/tudu-v1/blob/master/src/tudu/ui.cljs#L71

migrate tempids on response here: https://github.com/marianoguerra-atik/tudu-v1/blob/master/src/tudu/ui.cljs#L168

handle tempids in the backend here: https://github.com/marianoguerra-atik/tudu-v1/blob/master/src/tudu/api.clj#L34

Beautiful, thanks marianoguerra

i think managing tempids is different when using datascript...you can't update an id, unless it's another attribute

But yeah, not sure how you'd revert errors using this trategy

@petterik my approach is to remove the optimistically added thing and transact a new one

strategy*

(if successfully received from server)

So that's what I'm trying to do too

how do you identify all the added datoms/entities when you're removing them?

i send the tempid from the client side and have the server return it in :tempids so i can identify it

the only difference is that my merge function doesnt 'update' the tempids but removes and re-adds them

tbh i think we're pretty much on our own, don't expect too much help when choosing datascript at this stage

lots of things im not sure about

And by "send the tempid from the client side" you mean you've put a temp id in your call to (om/transact `[(your-mutation { <temp id here?> })]) ?

@petterik: you send it in the data, I send it in the :id field

marianoguerra: right. I'm assigning it in the :remote ast to get sync without having to change how we do mutations, but I might consider doing what you're doing.

as @marianoguerra said, im sending it in the data too on a :db/id key

i just generate a new one server side and send them both back

@marianoguerra: out of curiosity, why did you choose immutant instead of just, say, jetty?

danielstockton: Yeah, I'm surprised by all the answers really. Thanks! It's fun being early in the game 😉

Ok, cool

thanks to both of you

@grzm: I'm used to immutant, I used it for 2 projects and I know how to use it 😛

makes sense

I'm trying to limit the number of new things that I'm learning. I worked through the tempid stuff from tudu on Saturday and applied it to my own project. Very helpful!

@grzm: there's only one line of immutant in the example

Oh, I know. I just want to limit my dependencies. Hopefully fewer things to potentially go wrong. Nothing against immutant. The guys behind it seem really sharp.

@grzm: I understand, your reason is the reason I used immutant, even if it's overkill for this case

possibly me being dumb, but is there an om/build equivalent in om next?

@acron: there isn’t and that’s a good thing

@dnolen: Ok, so, I think the question I meant to ask is...will any sub-UI's be notified about the reconciler associated with the parent root?

@acron: I do not understand your question

also don’t see how it’s related at all to the previous question

@dnolen: lets pretend I never said anything and I'll come back when I've de-Om-ified myself

@dnolen: This is the problem I'm trying to solve - https://gist.github.com/acron0/66659295433a93819719#file-foo-clj-L49 <- It looks like 'Sub' doesn't know about the reconciler

@acron: sorry don’t have time to look at that

as the channels says, just direct questions to the channel not me

the main component doesn’t reference the sub’s query

queries need to compose down to the root

hueyp: So parent components need to query on behalf of their subcomponents?

yup

you use om/get-query Sub to compose the child query

this has some examples : https://awkay.github.io/om-tutorial/#!/om_tutorial.E_UI_Queries_and_State

and: "Common Mistakes Failing to Reach the UI Root"

hueyp: thanks for your help, will have a look!

@dnolen: my apologies! I thought it was obvious that the link was related to our earlier exchange.

OK - so another question: I have seen read methods that directly read items from the state using get-in - I have also seen db->tree - are there any rules around which to use and when? does db->tree cover the use case of doing (map get-in…. on the state? (Or is there something I have missed)

(defn get-todos [st]
  (into [] (map #(join st %)) (get st :todos/list)))

That being an example of what I am describing above. (Except, I think I have seen another demo using get-in instead of join

More "food" for the community: https://twitter.com/jannispohlmann/status/701836585638166528

Sending totally different mutation to a remote Hi everyone, I have a mutation on the client that needs to send a very different mutation to the remote- What is the canonical way to write this? I don't know how to format the AST data for the remote correctly- Just calling om/query->ast by itself causes an extra set of brakets to end up in the resulting data... Here is what I'm currently writing, which works great but is super ugly: :remote (first (:children (om/query->ast '[(foo)])))

@drcode (first (:children (om/query->ast '[(foo)])) gives {:dispatch-key 'foo, :key 'foo, :params {}, :type :call}, you could just use that directly in your mutation fn

@drcode: there's an ast included in your env 😉

(defmethod mutate :key [{:keys [query state ast] :as env} key _] ...)

@sander: Good point- I'm overcomplicating it, aren't I?

@iwankaramazow: Yes, but the remote needs a different mutation from the client AST, in my use case- I think @sander has the best idea: I should just write the raw AST.

@drcode: (om.next.impl.parser/expr->ast '(foo)) will give you what you need

Ahh! I remember seeing that function and then forgot about it! Thanks @anmonteiro

@jannis: cool stuff, have you been using it yourself?

@anmonteiro: I am using it. There are a few more features coming as well.

nice, I'll try it out soon

to clear up some of the confusion around current routing approaches in Om Next, I've written about a few different ways to solve the problem: https://twitter.com/anmonteiro90/status/701899774925131776

I have one component that wants to read both (:data {:from :yesterday}) and (:data {:from :today}). When I put both parametrised queries in the component's query vector, the props only contain one :data key. How should I redesign my parser/query to access both datasets from the component?

One :data key and make :from a vector?

Or split it up into :from and :to to define a range?

@jannis: thanks! the first makes most sense in my case

yw

@anmonteiro great write-up on routing, that will save me time. Thanks