This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-01
Channels
- # admin-announcements (3)
- # beginners (25)
- # boot (21)
- # cider (39)
- # cljs-dev (86)
- # cljsrn (20)
- # clojars (4)
- # clojure (70)
- # clojure-canada (1)
- # clojure-greece (101)
- # clojure-poland (16)
- # clojure-russia (35)
- # clojure-spec (202)
- # clojure-uk (24)
- # clojurescript (69)
- # cursive (23)
- # datomic (34)
- # devcards (7)
- # dirac (5)
- # editors (3)
- # emacs (6)
- # events (1)
- # hoplon (52)
- # instaparse (1)
- # jobs (4)
- # jvm (2)
- # lein-figwheel (2)
- # leiningen (10)
- # luminus (2)
- # mount (1)
- # off-topic (12)
- # om (55)
- # om-next (8)
- # onyx (19)
- # pedestal (4)
- # planck (1)
- # re-frame (27)
- # reagent (5)
- # remote-jobs (1)
- # spirituality-ethics (14)
- # tmp-json-parsing (6)
- # untangled (121)
- # yada (32)
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
@hkjels: :remote
must be returned at the top level too
If you only set it in the nested (recursive) parser only the callee will see it. Om needs to see it too
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
Is there a library for using d3 with om?
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/
@ashercoren: I know Untangled has an example of using it with Om Next, just looking for it now...
Here it is: https://github.com/untangled-web/untangled-tutorial/blob/master/src/tutorial/untangled_tutorial/B_UI.cljs
Thanks!
@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.
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?
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
@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
@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))}))
I want the action thunk to run
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
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
wait but it’s an atom, so it shouldn’t matter...
so that’s the issue — state
is not the same when building the remote ast
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?
sorry, copied the wrong code up there, just updated
@noonian: I thought that would work, but it doesn’t seem to be
the definition of old-value is executed once for the remote and once for the local action
@ethangracer: yea, it is executed a second time, for the same reason the mutation code has to be inside the thunk
I wonder if you can include the new value in a param
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
then it would be the same in the AST and in the action thunk
separately from the state atom
would it? I’m not sure
yes if you passed it as a param in the transact!
call
I don’t have access to the whole state when I call transact!
just my component
If instead of passing a parameter, I want to base my transaction on data already in the app-state, I’m screwed
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
@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
this is of course relying on implementation details, so you should be aware of that
local parsing occurs before remote parsing
gather-sends
is where remote parsing occurs
yeah that is the practical solution, I guess it strikes me as kind of an odd api
obviously we need access to the state atom to modify it
AND I would hope that each execution of the mutation could have a copy of the app-state before all the executions were initiated
there may be a very good reason that isn’t happening
@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
exactly, yes
let me sleep on that and I’ll get back to you in a few days
we don’t want the remote to rely on app-state that has already advanced
sounds good, thanks for hearing me out