Fork me on GitHub
#om
<
2015-11-18
>
dvcrn01:11:05

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

leontalbot03:11:27

Excellent talk @dnolen :-)

tomayerst08:11:59

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

tomayerst08:11:54

Hi, I suspect I am being dense. I’m working through: https://github.com/omcljs/om/wiki/Queries-With-Unions and I’m getting the following in figwheel: om-tutorial.core=> (om/tree->db Dashboard init-data true) WARNING: Use of undeclared Var om.next/tree->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!

griffio10:11: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.

tomayerst10:11:46

Ah! progress! simple_smile

tomayerst10:11:57

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

tomayerst10:11:04

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

tomayerst10:11:22

btw the profile.clj on https://github.com/awkay/om/wiki/Quick-Start-%28om.next%29 still has [org.omcljs/om "1.0.0-alpha3"]

griffio11:11: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 https://github.com/griffio/om-next-tutorial. May help you to compare your setup if encountering mystery errors.

tony.kay13:11: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.kay13:11:50

I'll remove those outdated docs

tony.kay13:11:31

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

tony.kay13:11:42

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

tomayerst13:11:57

@tony.kay: Is there a root link?

tomayerst13:11:35

for om next?

leontalbot13:11:57

The root link for om next docs is here: https://github.com/omcljs/om/wiki#om-next

tony.kay14:11:54

links fixed

tomayerst14:11:59

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

tomayerst14:11:28

not carefully enough to work out the exact fix though 😞

tomayerst14:11:47

more a blow it all away and start again thing

paulb16:11: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?

joshfrench17:11: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.

joshfrench18:11: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!"}}},
 :om.next/tables #{}}

tony.kay20:11:08

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

tony.kay20:11:31

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

tony.kay20:11: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.kay20:11: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.kay20:11: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.kay20:11:22

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

tony.kay20:11:02

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

tony.kay20:11:54

whereas the :people (local) read doesn't need details...it 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.kay20:11: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

martinklepsch21:11:58

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?

dnolen21:11:18

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

joshfrench21:11:29

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

dnolen21:11:45

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

dnolen21:11:56

esp. from a functional perspective

dnolen21:11:35

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

jgdavey21:11:44

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

dnolen21:11:29

See merge!

wilkerlucio21:11:10

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

tony.kay21:11:17

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

tony.kay21:11:22

and it seems due to dynamic queries, I only know the real queries in the context of the component (e.g. this)...so 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?

jannis21:11:31

@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: https://github.com/swannodette/om-next-demo/tree/master/todomvc/src/clj/todomvc

jannis21:11:25

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

tony.kay21:11:49

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

wilkerlucio21:11:47

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

wilkerlucio21:11:05

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

jannis21:11:47

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

tony.kay21:11:08

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

tony.kay21:11:36

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.

tony.kay21:11:01

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

tony.kay21:11:29

WARNING: Work in progress. https://github.com/awkay/om-remote-tutorial 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).

tony.kay21:11:03

It works like the other Om tutorials...run via script/figwheel

tony.kay21:11:32

It simulates server delay with a setTimeout of 1000ms

tony.kay21:11:49

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

tony.kay22:11:34

just pushed a few cleanups

noonian23:11:33

for any emacs users:

noonian23:11:38

(add-hook
       'clojure-mode-hook
       (lambda ()
         (put-clojure-indent 'defui '(1 nil nil (1)))))

martinklepsch23:11:37

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