yep. I used add-root! and it’s re-rendering fine now. So it was devcards.

With queries in Om Next, is it possible to get a query if for some reason there are a pure component between two components with queries?

@roman01la: yes that should work

all components have parent pointers that are used to crawl the hierarchy

some caveats here for random JS React components you might integrate, but I don’t think a real problem for the most part since I don’t see much value in these existing anywhere but at the leaves

@dnolen: I don’t know if there exists any reasonably big apps built with Om Next, but what’s the practice of using components with queries in Om? For example in JS world it’s common that you don’t want much of these “data aware” components on a single view.

@roman01la: I do not know what you asking

either you misunderstand the goal or you are phrasing your question strangely (for me anyway)

as to the JS world - there is no real innovation in the JS world wrt. UIs

it’s the same techniques long in practice in traditional OOP-y UI work

(React is a rendering thing which why you have a crazy number of approaches - nobody sorted it out at all that well yet)

@dnolen: Sorry. I mean, usually when I’m doing a project with React in JS, I have as less as possible components which are somehow connected to application state. I'm trying to understand if it's the same with Om. Should I have only a few components with queries and pass data down the tree using props?

Or should I use queries extensively across the whole app.

@roman01la: you can do whatever you want

pure components are still useful

if a component doesn’t need queries don’t use queries

@roman01la: the point of queries is directly tied to the fact that data comes from “somewhere else"

and that you want components to specify what they need yet achieve total coordination of UI state synchronization

everytime you hear somebody struggle with React and synchronization, caching hacks, uncoordinated fetches, async props

all this stuff

you should think - that’s a mess

and Om Next just gets rid of that via queries

@dnolen: Now I understand, thanks. One more question: I’m trying to figure out how to validate queries on the server. It sounds cool that client can ask for data it needs, without adjusting code on server. But what if there’s auth, some permissions for data access. Wouldn't this still require you to go and change something on server?

Om Next is actually 100% agnostic about the backend

I feel like I still need to write some validation logic for every type of request.

it just passes along a query and it’s up to the server to deal with it

traditional approaches apply - the only difference is that it not a single requests

but a fan out of requests

@roman01la: yes Om Next doesn’t try to magically solve the validation problem, that’s code you would have to have written anyway

you can in fact think of queries as getting a bunch of REST requests all at once

so it’s no easier or harder than it was before wrt. to validation / authentication

the benefits are simplification for clients and simplification for backend to be able to service many clients without even more bloating than you already have

this rationale btw is well covered by Relay & Falcor

Om Next provides little in the way of novelty here

Thanks. Now I need to think about it.

I'm a bit confused as to what keys I need to provide a defmethod read for. Is it only the top-level keys of the root component's query? I've been assuming that read was meant to be recursive, but I haven't seen any examples of that.

That is, if I have posts and comments, should (defmethod read :posts …) be returning the comments as well?

If I query for [{:posts [:body {:comments [:body]}]}], should that end up reading from a (defmethod read :comments …) or just (defmethod read :posts …)?

@peeja: read can be recursive but it’s not strictly necessary

it depends on how much you can leverage db->tree

in the big picture read is not even necessary

parse is a completely abstract thing

you can implement it however you want

the current read mutate split is provided just as a stepping stone / default

@peeja: gotta run but you should look at what people like @jannis and @tony.kay are doing for examples of using db->tree to take care of this. That or look at the devcards in Om itself.

Ah, okay, that makes sense.

Thanks!

I get the feeling that there are a lot of things in Om Next that make it easy/possible for lots of different things to work, but I've been assuming I'm supposed to be using all of them.

can anyone help me understand why the parser changes the type of tempids when performing reads on the jvm? Check out the snippet below...

because of this I can’t use tempids from query results to lookup values from :om.next/tables in my jvm code

in case you are wondering why I’m doing in clj and not cljs, I’m testing the dev workflow of using cljc to build an om.next app and only using cljs for the app and components

@steveb8n: that’s the same issue reported by @r0man, records don’t get preserved currently

If you have two components that render the same data—say, a PersonOverview that shows up in a list of people, and a PersonDetails that renders a larger view—how do you choose which to put the Ident definition on? Do you need it on both?

@peeja: you can use idents more than once

simplest way to keep things in sync

Doesn't that mean duplicating code? My instinct is that that would be a potential problem.

duplicating what code?

Duplicating the Ident definition

this is not a problem

yes you will have to write 2 lines of code

Right, I'm not worried about writing an extra 2 lines, I'm worried about it changing in one place and not the other. But maybe it's just simple enough that it doesn't matter?

so write a shared function to compute ident and call that instead

then you can change it one place

Yeah, fair enough. That makes sense.

Ah, right, so reusing that function is how you actually say "These components use the same thing"

yep

Awesome, thanks!

I know we're celebrating it early in Germany but: Merry Christmas everyone! It's been a pleasure joining this awesome community and I hope you all enjoy a peaceful time with friends and families.

I have hopefully a simple question. I have a top level component that pulls a key for a query, and then doesn’t re-render when I update that key in the app state. But, this only happens the first time I update the state. After the first update, the component re-renders. Is there some other part of the mutation that I need to check? I tried looking at returning :value from the transact! call, but that looks like it’s for dev convenience.

@mudphone: what does your transact! call look like?

`
(om/transact! this `[(page/select {:page ~page})])

(defmethod mutate 'page/select
  [{:keys [state]} key {:keys [page]}]
  {:value {:keys [:sentence/tucked :page/current]}
   :action (fn []
             (swap! state
               #(-> %
                  (assoc-in [:sentence/tucked] true)
                  (assoc-in [:page/current] page))))})

@sander: I’ve tried it a few ways… it turns out, it’s any component at the top level, tied to a key on the app state, when changed for the first time.

For example, if I just toggle :sentence/tucked it’s supposed to toggle a CSS class… but, it only runs render on that component after hitting it the second time.

@mudphone: there's no read in your transact call so nothing will be read

probably needs to look something like this:

(om/transact! this `[(page/select {:page ~page}) sentence/tucked page/current])

@sander: well that works… how did I totally miss this concept?

so, I need to read out the values that I’m updating in the state?

or that are relevant to updating my chosen components

@mudphone: you need to tell om to read out the values that you want to be read out after the mutation

@sander: thank you!

even if I don’t use them, just to be read out after mutation for the sake of updating the UI?

(just to clarify)

i have little experience with om.next, but that's how i think about it yes

'updating the ui' counts as 'using them' in my view

@sander, @mudphone: I think you can avoid this if your mutate fn returns {:value {:keys [:some/key]}}

I think

for some reason, I thought that was what the [:value :keys] vector on mutate was for.

@rhansen: I tried that, and it didn’t seem to work for me

i think the docs or the source docs say that :value is really just a hint that you as a dev can use

@sander: I see

@sander: it does, I was just desperate

oh

thank for the help

I think the answer for me tends to be, maybe I should have read the source

that’s 2 of 2 questions here so far

there’s a lunch with my name on in the next room… thanks for helping me out on your holiday!

glad to help enjoy your lunch

@sander, @rhansen: one note, I didn’t have to worry about this until I switched to having Om normalize my state for me… i.e. it’s not required if you pass the reconciler an atom.

(I think)