This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-01
Channels
- # admin-announcements (8)
- # arachne (11)
- # beginners (17)
- # boot (64)
- # cider (26)
- # cljs-dev (7)
- # cljsrn (1)
- # clojure (115)
- # clojure-belgium (2)
- # clojure-dusseldorf (15)
- # clojure-poland (15)
- # clojure-russia (62)
- # clojure-spec (86)
- # clojure-uk (208)
- # clojurescript (36)
- # cursive (4)
- # datavis (11)
- # datomic (44)
- # editors (9)
- # hoplon (21)
- # jobs (4)
- # mount (21)
- # off-topic (3)
- # om (113)
- # onyx (65)
- # parinfer (2)
- # perun (3)
- # proton (6)
- # re-frame (29)
- # reagent (20)
- # yada (3)
Is there anyone here who has played with error handling from serverside reads? I found the function default-extract-errors
in om.next which seems to return a list of errors and a result tree but i am not sure how to hook it up
I have the following case someone tries to read a list of something but they could have no permissions to read this list so then I want to show a message that they have insufficient permissions
Oh I think you can use this in the read functions if I read the tests correctly?
@mitchelkuijpers: I haven’t used it or looked too much at it, but I think it’s supposed to be used in merge
i.e. extract the errors from the result whenever you’re merging the remote response
Yeah looks like it
I also think the work on that is not finished, and I believe it’s going to be part of default-merge
in the future
Aha that would make sense, I think it is a good idea then to keep the om.next/error responses in my reads and do some custom work for now
we also did some work to create a after-mutate function that reads mutation responses and responds to them en keeps them out of the app state
anyhow thnx @anmonteiro
It's just like passing params except it doesn't factor into shouldComponentUpdate
, right?
Not really, but what I mean is, when you do your mutation your back-end should return novelty that’s merged back in to your app-state. At that point your view will be updated with the new data
@krchia: (goog.object/set the-object “foo” 42)
@anmonteiro: isn’t that the same as (set! the-object “foo” 42)?
that would be (set! (.-foo the-object) 42)
, which might break with advanced optimizations
i was thinking of (om/set-state! owner the-object (some-function-that-returns-object-with-new-property)
@krchia: so set-state!
will completely overwrite the existing state
@krchia: you also have doto
which might be useful for these cases
;; returns the-object
(doto the-object
(set! x y))
@peeja: not sure what’s the difference between update-state! and set-state! - the docs aren’t making it clear for me
perhaps you might know a better way - i’m just working with the d3.layout.tree structure
just trying to implement this example, where you push new nodes into both the nodes structure and as a children of a parent node
Typically in d3 you're just getting new data an re-drawing your d3 stuff over the existing DOM, correct?
i’m not doing that for now - to make things simple i have a vector of pre-generated data to test it with
Each time your component gets different data, it'll re-render. The actual render
isn't going to be interesting, but it'll also call will-update
, and that's where you call your d3 code from.
There's a bunch going on here, but this may be a useful example: https://github.com/circleci/frontend/blob/dbfad41b58f6107d51013e86e63f05379022eb90/src-cljs/frontend/components/insights.cljs#L374
The trick is that it sounds like you're passing in non-CLJS objects as the data. Is that right?
The reason I'm calling out passing in JS objects as the component's data is that Om depends on being able to =
the old params and the new params to see if they've changed
ah, it’s the “add a new node to a random parent” part in the d3 code, because if i don
So, if you want this to run as an animation, you'll want to have something on the outside that re-renders the component every X ms with the new data
Ah, you know what, to really use Om, you'll want to put the node data structure in the app state, and then kick off something that changes that state over time
So, each tick, the app state atom points to a new tree of nodes, exactly like the last, but with one random node added
Then Om notices that the state atom has changed, so it passes that value into the component
Then the component converts that into more JS-y values (if necessary), and passes that to d3
It just means putting the ticking mechanism inside the component (which I guess is what you've done)
i think i’m going to try that approach - storing the data in clojure data structures, then converting to js data only when d3 needs it
@krchia: I haven’t been following the whole discussion, but for performance you might want to keep JS datastructures
@anmonteiro: what - i was just about to switch back to my editor!
and deal with the Om diffing part by having a monotonically increasing value in your local state that you increment whenever you mutate the JS object
js->clj
and clj->js
is heavy on performance