Fork me on GitHub
#om
<
2016-06-01
>
hkjels06:06:29

If I run the parser recursively and hit a :remote, should it not execute send?

hkjels06:06:18

Or do I have to pass it all the way up to the root and add :remote to it?

hkjels06:06:59

That didn’t make any sense, sorry. Let me rephrase

hkjels06:06:37

Crap! My kid just woke up. Later..

hkjels09:06:37

I’m back.. So, simplified. What is needed for a send to occur?

hkjels09:06:48

If I mount a component as root whose query touches a reader with a :remote-key, send occurs. But if I instead have another root-component that includes that component, the send does not occur. Even though I run the parser recursively

hkjels09:06:35

So, there must be one more ingredient that I’m missing

anmonteiro10:06:37

@hkjels: :remote must be returned at the top level too

anmonteiro10:06:33

If you only set it in the nested (recursive) parser only the callee will see it. Om needs to see it too

hkjels11:06:16

I’m probably messing it up in some other way then. I can make the root-component ask remotely, but the dispatch-key will be that of the root-component then

ashercoren15:06:07

Is there a library for using d3 with om?

hlolli15:06:20

Not as far as I know, but there exists a react-d3, just encourage someone to upload it to http://cljsjs.github.io/, there are some ways you can go to create externs, I'm a newb in that area. http://www.reactd3.org/

cjmurphy15:06:17

@ashercoren: I know Untangled has an example of using it with Om Next, just looking for it now...

cmcfarlen15:06:11

@ashercoren: I've had pretty good results just keeping the visualization separate (using just cljsjs d3) and then kicking updated data to the visualization in componentDidUpdate and friends. I do try to keep the d3 side as stateless as possible though.

ethangracer21:06:47

question about mutations. I want to toggle a boolean value somewhere in my action thunk, and send that boolean value off to the remote. When I access state in the action thunk to modify the boolean, then when the mutation is called a second time for the remote, the boolean has already been toggled. is there a way to access the value before the local action thunk was executed?

ethangracer21:06:09

seems to me like the value at a given location in app state should be the same for all local and remote executions of the same mutation, but om’s behavior indicates each execution is completely independent

anmonteiro21:06:39

@ethangracer: I’m failing to understand your question because the action thunk is only meant to be run once. If you’re seeing that it gets run twice that’s probably a bug

ethangracer21:06:19

@anmonteiro: yeah I’m having a hard time describing, here’s a code sample

(defmethod mutate 'survey/toggle-publish [{:keys [state ref ast]} _ _]
  (let [old-value (get-in @state (conj ref :survey/enabled))
        new-value (not old-value)
        remote-ast (assoc ast :params {:survey-id (second ref)
                                       :survey-enabled new-value})]
    {:remote remote-ast
     :action
             (fn [] (swap! state assoc-in (conj ref :survey/enabled) new-value))}))

ethangracer21:06:32

I want the action thunk to run

ethangracer21:06:09

when I access the state in the action thunk, AND when I access the state to build the remote ast, I expected to receive the same state

ethangracer21:06:40

but it seems that the state I access when building the :remote portion of the keyword is different, since the state isn’t closed over by the action thunk

ethangracer21:06:56

wait but it’s an atom, so it shouldn’t matter...

ethangracer21:06:44

so that’s the issue — state is not the same when building the remote ast

noonian21:06:13

Can you just deref the state before returning the map with the :action key and use the value from the deref’ed version for both?

ethangracer21:06:08

sorry, copied the wrong code up there, just updated

ethangracer21:06:30

@noonian: I thought that would work, but it doesn’t seem to be

ethangracer21:06:12

the definition of old-value is executed once for the remote and once for the local action

anmonteiro21:06:35

@ethangracer: yea, it is executed a second time, for the same reason the mutation code has to be inside the thunk

anmonteiro21:06:41

I wonder if you can include the new value in a param

ethangracer21:06:10

I think I’m missing something? the mutation code has to be inside the thunk so it’s closed over, I get that. What I don’t understand is why the state before the mutation is run isn’t provided in the environment

anmonteiro21:06:10

then it would be the same in the AST and in the action thunk

ethangracer21:06:13

separately from the state atom

ethangracer21:06:30

would it? I’m not sure

anmonteiro21:06:43

yes if you passed it as a param in the transact! call

ethangracer22:06:23

I don’t have access to the whole state when I call transact!

ethangracer22:06:35

just my component

ethangracer22:06:04

If instead of passing a parameter, I want to base my transaction on data already in the app-state, I’m screwed

ethangracer22:06:43

maybe it’s in a part of the app state that my component doesn’t have access to in props, but needs to modify both locally and on the remote

anmonteiro22:06:11

@ethangracer: the easy solution would be to negate the value in the action thunk and have the AST be built with the value in the state

anmonteiro22:06:25

this is of course relying on implementation details, so you should be aware of that

anmonteiro22:06:42

local parsing occurs before remote parsing

anmonteiro22:06:49

gather-sends is where remote parsing occurs

ethangracer22:06:19

yeah that is the practical solution, I guess it strikes me as kind of an odd api

ethangracer22:06:30

obviously we need access to the state atom to modify it

ethangracer22:06:00

AND I would hope that each execution of the mutation could have a copy of the app-state before all the executions were initiated

ethangracer22:06:33

there may be a very good reason that isn’t happening

anmonteiro22:06:03

@ethangracer: it also makes be wonder if that wouldn’t be desirable for this use case, a bit like Datomic provides you with :db-before and :db-after

anmonteiro22:06:41

let me sleep on that and I’ll get back to you in a few days

ethangracer22:06:48

we don’t want the remote to rely on app-state that has already advanced

ethangracer22:06:53

sounds good, thanks for hearing me out