Fork me on GitHub

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


Excellent talk @dnolen :-)


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


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!


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


Ah! progress! simple_smile


Now I have om-tutorial.core=> (om/tree->db Dashboard init-data true) #object[TypeError TypeError: Cannot read property 'call' of undefined]


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


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


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


@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


I'll remove those outdated docs


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


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


@tony.kay: Is there a root link?


for om next?


The root link for om next docs is here:


links fixed


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


not carefully enough to work out the exact fix though 😞


more a blow it all away and start again thing


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?


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.


=> (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!"}}}, #{}}


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


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


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


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


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


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


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


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


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


I was wondering if there are any thoughts with regards to animation in Om.Next? Is there anything novel that might help with animations or would I still just use the React addons?


@martinklepsch: nothing novel, I’m a bit surprised someone hasn’t come up with something specific to Om.


@tony.kay: so rather than manually returning some slice of state, i should append a read that targets the relevant bits instead. is that the gist?


@martinklepsch: lazy sequences for animation transitions seem like an interesting idea to pursue to me


esp. from a functional perspective


one of the React folks had done some work here via Mori and it seemed like a really promising direction


@dnolen: You mentioned being able to “side-load” information in your talk yesterday. Are the mechanics of that already available in the alphas?


See merge!


hello people, there is any example code using a HTTP remote for that I can look at? or any sort of async remote will be nice too


@joshfrench: I believe so...I'm going to clarify with David. @dnolen If i want to force a remote read with, say, ':people, I see just the keyword coming into send, which I understand (which query do I want?). but to really send to the server I want some kind of real query (with joins from root, right)


and it seems due to dynamic queries, I only know the real queries in the context of the component (e.g. this) I'm assuming I'll send a forced read that is more of a rooted query. Can I use path to just pare that down like ui->props does?


@wilkerlucio: David's todo demo has a server component that receives queries (reads and mutations) over HTTP and parses them with om's server-side parser:


@wilkerlucio: I haven't seen any examples of using a regular REST service as the backend but it's simple - all you have to do is translate requests/responses from and to Om query expressions.


@wilkerlucio: I'll be adding more remote docs in the next few days as well


thanks guys, I'm trying to figure out the client side part, I believe :send at the reconciler was my current missing point, playing with it


@tony.kay: will be awesome to have more docs there, looking forward to it


@wilkerlucio: Yep, implementing :send is what you need to send stuff over to the server and call Om's merge function once you have a response.


@joshfrench: The mutation is...well, a mutation. The follow-on reads are you chance to fetch things. If you include local keys (e.g. :people) then your local parser will get hit for a root query, and only those components mentioning :people will re-render. Now, if you write your local read methods to return :remote true from that parse, then you'll get remote reads from that...but that implies your mutation will have marked something in state so you know to do that.


Whereas, say it is a remote mutation. if you quote the keyword (`:people`) then it will end up including that "read" in the send for the mutation.


I'll stick my example up on github, and you can play with isn't documented much yet, but it is handy to play with for remotes.


WARNING: Work in progress. This is mostly undocumented source, and it does not do a "complete thing". It is a simulator environment for seeing what happens with send, and how optimistic updates work, as well as server denials, etc. Basically, it allows you to "add a person" once and only once. Depending on what lines you uncomment in send, it simulates the server response for a good add or a failed add. Delete only works after add, and only once (again, a sim, not meant to work after that).


It works like the other Om via script/figwheel


It simulates server delay with a setTimeout of 1000ms


Very useful for light testing to see how things "should" work


just pushed a few cleanups


for any emacs users:


       (lambda ()
         (put-clojure-indent 'defui '(1 nil nil (1)))))


@dnolen: @jannis haha who else than @chenglou could have done it 😄