Fork me on GitHub
#om
<
2016-07-13
>
hlolli11:07:47

As om.next is designed around avoiding chain reaction. I'd be curious to know a cleaver way to mutate the client state and use the result of that mutations and send it to remote. Instead of calculating twice an operation, one for client and one for remote. It's basically a button I have, that when pressed it transacts and the remote would need to know the calculated client state to give the right response. Is this something in the realm of om/computed?

hlolli11:07:15

Maybe most simple would be if there is a way to seperate :remote and :action, where it would be possible to do some operation on client before sending data to :remote. As far as I understand, :remote is only a boolean?

anmonteiro12:07:43

@dnolen: React 15.2.1 is up in CLJSJS

anmonteiro12:07:52

I can confirm upgrading to that fixes #673

anmonteiro12:07:09

Happy to submit a PR with a devcards example too that demonstrates the issue being fixed

anmonteiro12:07:39

@dnolen: also found the change that fixed this

anmonteiro12:07:52

it was fixed from 15.1.0 -> 15.2.0

dominicm12:07:34

@anmonteiro: Thanks for the cc, highly appreciate it. The issue was as I thought it was from the discussion the other day, (switching to hasOwnProperty for checking). Interesting bug. Bloody js.

anmonteiro12:07:34

@dominicm: sure, no problem. Also happy when these fixes happen upstream, so we don’t have to change code that worked before in Om

dominicm12:07:57

Always a plus! Although, it must mean saying "Don't use this with these React versions: A, B, C" ?

anmonteiro12:07:25

@dominicm: I’m not expecting that to be a problem, as React is bundled with Om

anmonteiro12:07:41

and we keep it fairly updated

anmonteiro12:07:59

and from where I see it, people should be using the latest alphas anyway 🙂

dominicm12:07:39

Derp, of course it is. And like you said, alphas!

anmonteiro13:07:48

@dnolen: just realized I forgot to bump React in pom.xml in my PR

dnolen13:07:09

@anmonteiro: not a big deal since we don’t use that for the artifact that everyone gets

dnolen13:07:14

I’ll fix it in a bit

anmonteiro13:07:32

@dnolen: I was planning on looking at #637 and #604 today, did you get a chance to read @tony.kay ’s comments in those?

anmonteiro13:07:49

basically the gist of the solution to “`db->tree` naively resolves idents” is looking at the normalized tables to see if the first component of the ident exists, and only attempt to resolve it if that’s true

dnolen13:07:02

@anmonteiro: I haven’t, that idea sounds reasonable to me at the moment

anmonteiro13:07:37

@dnolen: #604 is “Denormalized joins not included in db->tree result” which, if I remember correctly, would partly be solved by tackling #637

anmonteiro13:07:45

i.e. we try to detect ident, if it doesn’t exist we use the denormalized stuff

anmonteiro13:07:18

@dnolen: I’ll take a stab at it and submit a PR for your review if I come up with something that works, if that sounds good

ethangracer15:07:54

@hlolli when the parser runs, it executes the action thunk first and then runs each remote. So, if you modify the app-state in the action thunk and you want to send that modification to the server, you can pull the modified data from the app-state to send it off

ethangracer15:07:55

om/computed is used to pass data not specified by a query to a child component — purely a UI concern, not relevant inside mutations

hlolli15:07:42

@ethangracer: Ok, I was passing the updated data as parameter and I usually avoid dereferencing the app-state inside component. I assume as soon as the component rerenders after the transaction the new state will be available. For this reason I ended up just calculating twice, most of the transaction parameters I'm sending to remote don't need any operation. So I guess the performance I'm losing is very small. But nice no know about om/computed, I usually loose the data which is passed without querying it before it pops up again.

hlolli15:07:42

But where I loose the data that is passed to component without query, I use the chance to display some "loading.." indicator. Works well that way, probably other better way to indicate "loading..".

ethangracer15:07:50

you can intentionally put some kind of marker in your app-state to designate that data is loading, rather than relying on the query engine to fill in the gaps

akiel16:07:09

Is there doc what the parser returns for mutations? I’m on the server. Is it important to return the mutate results to the browser?

dnolen16:07:04

the expectation is that mutation not return anything at all except what keys might be interesting to reread

akiel16:07:55

and the rereading is handled in the browser parser?

dnolen17:07:31

there’s nothing automatic here, your application explicitly declares what it wants to reread in the transaction query

akiel17:07:44

and :keys in :value of a mutate function means nothing?

dnolen17:07:55

it means something

dnolen17:07:59

but it doesn’t trigger anything at all

dnolen17:07:32

the client needs to explicitly describe what it wants

dnolen17:07:40

every client is going to care about a different set of things

akiel17:07:02

is there some doc about tempids? I find various things about them but nothing comprehensive in the wiki

dnolen17:07:17

not beyond what’s in the wiki

akiel17:07:33

ok thanks for now

anmonteiro21:07:24

@dnolen: just submitted a fix to the naive resolution of idents in db-tree https://github.com/omcljs/om/pull/725

anmonteiro21:07:41

seems quite straightforward, but do let me know if there’s something that doesn’t look right

anmonteiro21:07:59

also accepting suggestions for the mappable-ident? function name