This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (4)
- # beginners (14)
- # boot (41)
- # capetown (1)
- # carry (10)
- # clojure (168)
- # clojure-czech (11)
- # clojure-mexico (3)
- # clojure-quebec (1)
- # clojure-russia (63)
- # clojure-spec (108)
- # clojure-uk (44)
- # clojurescript (37)
- # component (5)
- # data-science (2)
- # datascript (5)
- # datomic (3)
- # defnpodcast (9)
- # dirac (14)
- # emacs (18)
- # events (1)
- # funcool (2)
- # garden (2)
- # hoplon (48)
- # leiningen (6)
- # numerical-computing (1)
- # off-topic (8)
- # om (61)
- # onyx (22)
- # proton (14)
- # re-frame (50)
- # reagent (2)
- # uncomplicate (1)
- # untangled (41)
- # vim (5)
- # yada (5)
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?
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?
Happy to submit a PR with a devcards example too that demonstrates the issue being fixed
@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.
@dominicm: sure, no problem. Also happy when these fixes happen upstream, so we don’t have to change code that worked before in Om
Always a plus! Although, it must mean saying "Don't use this with these React versions: A, B, C" ?
@anmonteiro: not a big deal since we don’t use that for the artifact that everyone gets
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
@dnolen: #604 is “Denormalized joins not included in
db->tree result” which, if I remember correctly, would partly be solved by tackling #637
@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
@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
om/computed is used to pass data not specified by a query to a child component — purely a UI concern, not relevant inside mutations
@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.
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..".
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
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?
the expectation is that mutation not return anything at all except what keys might be interesting to reread
there’s nothing automatic here, your application explicitly declares what it wants to reread in the transaction query
is there some doc about tempids? I find various things about them but nothing comprehensive in the wiki
seems quite straightforward, but do let me know if there’s something that doesn’t look right