Can anyone confirm if om 1.0.0-alpha22 is technically "stable" for the purposes of running om.now with React 0.14

I'd like to try https://github.com/JedWatson/react-select but it requires react 0.14 and om 0.9 release depends on 0.13

@olivergeorge: pretty sure the alphas aren’t good for om.now

that probably won’t get settled until we get closer to beta

hello; I've been using om for a while & am trying to figure out om.next

I am kind of confused as to how :remote mutates work; I wrote a simple example based on @dnolen 's TodoMVC, but when I try to add an element the change isn't reflected on the client

i.e. I do (om/transact! s [(foo/create {:foo/name "new-name"})] which goes to the remote fine, and if I update I see the new foo

but it isn't reflected in the client until I refresh

The remote is is giving {:value [:foo/list]} but that doesn't make it reload that? I also heard mention of using temp-ids with automatic reconcilliation in the clojure conj talk, as that what I should be using here? optimistic update on the client with temp-id?

@jamesnvc: {:value ...} has no impact on re-render, it is only a suggestion. In a transaction, you'd append the key... so change your transact call to: [(foo/create {:foo/name "new-name"}) :foo/list]

If you want to see what components would be re-rendered based on :foo/list, do: (om.next/ref->components reconciler :foo/list) in your repl.

Thanks @dnolen

Thanks @tony.kay - that remotes simulation example is really useful

morning people, does anyone have an example repository with Om.next + Devcards + Reconciler?

@wilkerlucio: I think @jannis has some devcards + om.next stuff

My Om Next devcards don't use the reconciler. But these do: https://github.com/omcljs/om/blob/master/src/devcards/om/devcards/tutorials.cljs

^ @wilkerlucio

humm, thanks @jannis

I see this code uses a function om/mock-root, interesting

thanks @martinklepsch, I was looking at @jannis code before, but like he said he wasn't using reconciler there

Thanks @bplatz, I'll give that a try

So I heard mention of this :tempid map in @dnolen 's Clojure Conj talk & I see where it gets called in om/next.cljs, but how do you actually use it? Do you make the action thunk return {:tempids {1 2}}?

@jamesnvc: close. map from refs to refs

Generate tempids w/ (om/tempid). Then return {:tempids { [:thing/by-id tempid] {;thing/by-id real-id] } }

note: there is a bit more expansion coming in Om here related to action

@tony.kay: thanks!

hello; how are you handling temporary input values on om.next? are you using it as some local state or putting it on a root pointer like :something/new?

@wilkerlucio: either way could work, it really depends on whether you want to time travel on that state

I might put edit state in app state

but not transient input field value in app state

thanks @dnolen, I'm gonna try using edit state in app state

How often should we be updating the Documentation page for om.next? I see set-params! still on there

I know set-query! has sort of absorbed this functionality

I can update too, if ya'll want - I've been in lurking mode, because I don't know how things work yet

@jonsmock: it’s better to ask first as you have

feel free to fix in this case

Ok thanks

Removed the set-params! and updated set-query!

https://github.com/omcljs/om/wiki/Documentation-%28om.next%29#set-query

thanks

So I continue to be confused how :tempids work

My action returns something like {:tempids {[:foo/by-id tmp-id] [:foo/by-id new-id]} but I don't seem to see that reflected in the client

@jamesnvc: could be a bug, but i would isolate your problem

you can test the :tempids in 20 lines of code

the tests in om.next itself are trivial

should I expect to see the id updated in the client though? I'm not even sure what I'm doing makes sense

like, it should automatically re-render components that have that old id?

as long as you said you wanted to in your transaction

there might be a bug though

but again I would only look at something minimal and complete that demonstrates the issue

okay, I will try to isolate, thanks!

np

I have no prior Om, React or ClojureScript experience and am going through the Om Next tutorial. Curiosity question... is there a way to call transact! in a for loop but still have the components re-render before the loop is complete? (for [x (range 1000)] (om/transact! reconciler '[(increment)])) This logs the transactions to the console but my Counter component doesn’t re-render until the loop is complete.

@balduncle: I don't think so, by design; React only re-renders on requestAnimationFrame, precisely so it doesn't have to repeatedly re-render 1000 times

jamesnvc: Okay, thanks. I’ll see if I can find some React doc about this.

@jamesnvc: rAF is not a React thing

it’s a Om thing

Oh, my bad

@balduncle: and no you don’t want do that (clarified)

I only know React in the context of Om, so I'm not sure what is what 😛

it’s precisely the kind of thing that Om discourages

you can override the behavior but it’s not recommended at all

should it be possible to call update-state! from a componentWillUpdate? I'm getting a No queries exist for component path error when I try to do so

I've found that when I have a component that receives modified props that are partially from Om.next + extra data, then I update the component state, all props are lost in the next render cycle, is that normal?

@wilkerlucio: that’s another anti-pattern

you can’t do that anymore in Om Next

see om/computed

If you had a constant stream of data coming in that needed to be transacted I assume it wouldn’t lock up the UI if it was coming in super fast…?

I have a list that loads async from the server. I want to set a local :selected-item attribute when the list first loads for a default selection

if you need to add some side information

@balduncle: the whole point of rAF is who cares how fast the data is coming

you’re never going to see anything more than 60fps anyway

@dnolen: nice, that's what I was looking for, thanks

dnolen: I won’t even see that though if my loop is stopping rendering from happening, right?

@balduncle: yes but that doesn’t have anything do with Om

that’s how JS works

Okay

if you have an expensive loop you block the browser from repainting period

Got it. Makes sense.

@rads just not enough information in your question

the server bits aren’t really relevant to the issue

you should be able to show a minimal example of what isn’t working for you

@dnolen: using om/computed the computed properties are kept after a state update, but props are still being lost, this is intended?

@dnolen: ok, let me get an example going

@wilkerlucio: doesn’t sound plausible

@wilkerlucio: you’re just not allowed to modify props periods

all that stuff has to happen in parse

components never touch props

@dnolen: I'm not trying to modify props, I'm updating the component state, I have a minimal case for the issue, let me paste for you

on this component, when you click at the button the props go blank

@wilkerlucio: yeah so that won’t work

you are breaking the contract between components

oh actually sorry

perhaps not

@wilkerlucio: and this is alpha22?

yes

@wilkerlucio: yeah your parse won’t work

{:value …}

oh you’re not even supplying a parser

not recommended, make a proper parser

the read you supply can of course just be a simple function

I don't understand the relation of the parser with the problem that I'm trying to point out

@wilkerlucio: nothing will work if you don’t supply a parser

because the parser here is just supposed to be a mock to get something that works

Sorry to keep asking questions about the same thing here, but I see that my action returns {:tempids …}, but the return value of the thunk doesn't get sent to the client? It is very possible I am misunderstanding how this is supposed to work

@wilkerlucio: the problem is the parser is broken

why when I update the child state it loses the props? I'm trying to understand this

@wilkerlucio: the components gets its props … from the parser

you’re just getting lucky the first render is all

@jamesnvc: the return the value of the thunk is never sent to the client that’s not how mutations work

the tutorials cover this

@dnolen: okay, that makes sense to me; I was confused how :tempids could possibly work in the way I was understanding

@jamesnvc: mutations return {:keys … :tempids …}

as the :value part, the actual mutation thunk is in the :action part

the result of most mutations are useless

db transactions etc.

oh, the :tempids is the in the :value? awesome

@jamesnvc: yep

@dnolen: thanks, working with a fixed parser

I guess I have to use something other than the datomic primary key as the id though? Since I need the result of the thunk to figure that out?

@wilkerlucio: the parser builds the UI

nothing works without

@jamesnvc: yes that needs to be fixed, legitimate bug

@jamesnvc: in the meantime I would thread an atom to collect this stuff

@dnolen: thank you very much, I think I understand what's going on now

@dnolen: Hey David, I had an idea for merge-tree that might help things out quite a bit...let me know if you have a few to chat abt it

or if you'd rather me just describe it in a issue

I'll do the latter.

@tony.kay: I’m going to be side tracked for the next few days on a bigger problem

so everything else is on the backburner for a bit

no biggie. I'm going to spend the next few days writing docs. I've written stuff down in issues

trying to see how hard it is model complex async coordination within send

i.e. typical hard stuff like autocompletion across the wire

I don’t see any challenges but want to make sure the API bits for manipulating queries is solid enough for this

sweet. Look at the issue I just submitted (482)...it relates.

(in that it is meant to make dealing with those queries and responses easier)

@tony.kay: after reading over it I don’t really understand it

might be easier with code

parsing the response doesn’t make much sense to me since you got back exactly that

ok, will do. I'll work up an example that shows what I'm thinking...doing that for the docs anyhow

send is completely in your control also

so pretty conservative around anything that is solveable in send

treat the response as the STATE...and what you sent as the query...

but instead of running read, run a node merge

at each ast of the sent query

still don’t get it

is this referring to the :query/root reconstruction stuff?

unrelated

yeah then I don’t get it

you want me to explain more, or just make code?

what I mean is I don’t get the point of it at all

probably because the issue doesn’t describe a problem

We often need to write merge-tree, since the UI tree doesn't match the structure or the app state, right?

e.g. the response from the server has to look like UI tree, but that isn't what is in our app state.

you have auto-normalization for really simple case

so, merge-tree is going to be a source of complexity in our code

and we can leverage the parser to address this complexity (since we already have the query we sent, and the parser)

I don’t see how the parser can help you

parser makes a tree too

if we do read, yes it does

but really, it is just traversal

and that thing has the exact same problem

what you might be saying is ...

it’s easier to merge tree + tree and then normalize that to get the new db?

nope

if you’re talking about extending the parser in some way

sorry, I am assuming that you write you read-style functions to call parser recursively

then that will need a lot more rationale

What I'm talking about requires no mods to parser

I'll show you in code...give me a day or so

k sounds good

it also doesn't require new code, really...but it gives nice help with the merge-tree problem

sure, yeah I just can’t understand anything from the issue itself at all

the add would be (om/parser {:read read :mutate mutate :merge merge})...but not even that is required

I'll stop distracting you and just write it