# om

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

tavistock 00:41:18

i am working on some docs pages that are just a wrapper around your wiki, because I saw there was an open issue about it. is there a om logo. I am just going to use blue and green like clj/cljs logos.

tony.kay 01:10:54

FYI: My Om Next Overview has been updated to include recent changes in naming. I'm working on the some docs for Mutation and Remotes next...coming soon.

chris-andrews 01:13:57

@tony.kay: Your overview has been really helpful–thanks for putting that together

tony.kay 01:14:17

welcome...more coming soon now that things are stabilizing

dvcrn 03:46:05

oh great, the om next talk from conj is on youtube

leontalbot 05:21:27

Excellent talk @dnolen :-)

tomayerst 10:20:59

Gonna have to watch it a few times, I blinked and missed some stuff :wink:

tomayerst 10:35:54

Hi, I suspect I am being dense. I’m working through: and I’m getting the following in figwheel:

om-tutorial.core=> (om/tree->db Dashboard init-data true)
WARNING: Use of undeclared Var>db at line 1 <cljs repl>

Other om/* functions are fine. I maybe climbing too many learning curves, can anyone tell me what I’m doing wrong? Thanks!

griffio 12:31:24

@tomayerst: If you are still having a problem, can only suggest to check you are using at least om "1.0.0-alpha22" as per quick start guide. "tree->db" used to be called "normalize” in various earlier versions. Also, try (clean-builds) in figwheel or just delete the resource/public/js files and restarting if you have older versions.

tomayerst 12:51:46

Ah! progress! :simple_smile:

tomayerst 12:51:57

Now I have om-tutorial.core=> (om/tree->db Dashboard init-data true)

object[TypeError TypeError: Cannot read property 'call' of undefined]

tomayerst 12:53:04

which I will investigate late , but (doc om/tree->db) which is much better

tomayerst 12:55:22

btw the profile.clj on still has [org.omcljs/om "1.0.0-alpha3"]

griffio 13:22:42

@tomayerst: It is fun to type out the quick start examples by yourself to learn it, and I have an up to date version of all the examples in one place May help you to compare your setup if encountering mystery errors.

tony.kay 15:18:12

@tomayerst: That file is David's old one. The only file in that Wiki to read is the Om Next Overview. All the rest you should use the Om site for

tony.kay 15:18:50

I'll remove those outdated docs

tony.kay 15:21:31

the links from mine might not work now, but at least they won't be pointing you at old docs

tony.kay 15:21:42

I'll fix them up more later when I have time

tomayerst 15:26:57

@tony.kay: Is there a root link?

tomayerst 15:27:35

for om next?

leontalbot 15:34:57

The root link for om next docs is here:

tony.kay 16:01:54

links fixed

tomayerst 16:11:59

Cheers, and I have got the om/tree->db working :simple_smile:

tomayerst 16:12:28

not carefully enough to work out the exact fix though :disappointed:

tomayerst 16:12:47

more a blow it all away and start again thing

paulb 18:40:20

I have a component function that uses both transact! and update-state! - called by themselves these correctly re-render the component, but called together only the change by update-state! is re-rendered. How can I make the component re-render to reflect both changes?

joshfrench 19:48:17

is it expected that remote mutations can return state changes? since the response is keyed off of the dispatch key, the return tree doesn’t necessarily merge directly onto the local tree.

joshfrench 20:03:46

``` => (defmethod mutate 'item/compute-a-thing! [{:keys [state]} _ _] {:action (fn [] (swap! state assoc-in [:post/by-id 0 :title] "Loading...")) :remote true})

=> (om/transact! reconciler '[(item/compute-a-thing!)])

=> (pprint/pprint @reconciler)

{:dashboard/items [[:post/by-id 0]], :post/by-id {0 {:id 0, :title "Loading..."}}, item/compute-a-thing! {:post/by-id {0 {:title "Loaded!"}}}, #{}} ```

tony.kay 22:37:08

@joshfrench: remote mutations can have "forced reads" by quoting the thing you want to post-read in the transact!

tony.kay 22:37:31

(transact! this '[(doit) ':thing-to-remote-read)

tony.kay 22:38:16

if your read isn't rooted in the UI tree, then you'll have to do some custom merge code to get it in the right place, I believe

tony.kay 22:38:32

(along with making your server understand what it is you really want to do with that read since it might not have all the context needed)

tony.kay 22:39:16

I was just playing with an example, because it seems you probably want to send a forced read to the server that includes current query with sub-queries in a join

tony.kay 22:41:22

which ends up sending this to the remote: {:remote [(app/add-person) {:people [:db/id :person/name]}]}

tony.kay 22:42:02

note the use of this in the get-query, which makes sure I'm getting the "current dynamic query" from the component

tony.kay 22:42:54

whereas the :people (local) read doesn't need is going to cause re-renders of components that asked for people as a prop, and the query will be re-derived from root

tony.kay 22:43:43

so in this example I'm doing both (optimistic update of UI, and remote re-read of the subquery). Om is not going to know how to merge this if it isn't from the root without help