This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-03-06
Channels
- # admin-announcements (1)
- # aws (12)
- # beginners (35)
- # boot (12)
- # cider (32)
- # cljsrn (5)
- # clojars (10)
- # clojure (20)
- # clojure-russia (60)
- # clojurescript (229)
- # community-development (14)
- # cursive (9)
- # data-science (4)
- # datomic (3)
- # funcool (2)
- # hoplon (29)
- # jobs (15)
- # jobs-discuss (53)
- # keechma (2)
- # luminus (8)
- # om (42)
- # onyx (15)
- # parinfer (22)
- # re-frame (12)
- # reagent (162)
- # spacemacs (1)
I’m writing D3 ui widgets, and I’ve got it working just fine, but I’m wanting to cross-check my beliefs: 1. I want shouldComponentUpdate to return false, so react doesn’t mess with the D3 generated DOM 2. I’m passing in props to send the data to D3 to render. Since I cannot use componentWillUpdate to pass this data along (it won’t be called, since I’m saying the component should never update), I need to do the updates in shouldComponentUpdate, right? If so, then I’m wondering about next-props, which isn’t unwrapped. I’m having to do this:
(shouldComponentUpdate [this next-props next-state]
(let [props (om/-next-props next-props this)]
(render-squares this props)
false))
This seems like a bug to me. When overriding this method the next-props should be easily usable…however, I’m game to do it this way, in which case I’d add it to the docs. Comments?all of the other lifecycle methods give you the props without having to call -next-props on them…but then again, -next-props exists.
@doglooksgood: No, but all you have to do is use merge!
on whatever you’ve brought in (arguments are the reconciler, the tree of data, and (optionally, but recommended) the query from the UI that can be used to normalize it…otherwise it uses the Root query)
Om Next itself is fine with you using web sockets or any other thing for communication. The send function is just a function, and it can send queries over anything
@tony.kay: beware of the https://facebook.github.io/react/blog/2016/01/08/A-implies-B-does-not-imply-B-implies-A.html
@iwankaramazow: Thanks for the heads-up. In this case, D3 will take care of the need for things to be idempotent.
@franz: without any context that's pretty hard to say. Generally speaking it's this pattern (om/transact! this-defui-component-or-reconciler [(mutation)])
@tony.kay I've got d3 going without componentshouldUpdate false and my d3 joins in didUpdate. It works, I guess because render only renders the div target and there are no diffs to push to the Dom.
I tried using render in the animation loop but that reran the Om queries and fps was really slow. Without that I'm now getting 70 fps
@iwankaramazow right, Im using transact! with the reference to the reconciler directly since at that point I am not in the context of a component
it is easier then using merge! since i can then use :action to swap the state. merge! is hard when the structure of the server events doesnt match like in my case..
and what's the problem exactly?
no problem :) it works. am just wondering if thats ok to use transact! instead of merge! to handle websockets push events
If the structure of the server event, needs a lot of plumbing to get into the right shape I would go with transact!. On the other hand, you can do a lot with plain queries.
@tony.kay: How to tell server that: this component is unmounted, and the client will not need this data anymore? I mean, how to register a query and unregister a query?
Is there a reason why Om documentation and resources seem so far behind Reagents?
@doglooksgood: Use the lifecycle hooks in React for mount/unmount and use transact! to run mutations.
@steveb8n: I did some first drafts and it seems ok, but it really seems like shouldComponentUpdate should return false if the changes in props should not call render. Perhaps react isn’t diffing the content because those bits are not react components. When I look at the code for the d3-react-wrap at https://github.com/skellyb/react-d3-wrap/blob/master/src/index.js, it doesn’t override shouldComponentUpdate either.
@dnolen: rebased latest dynamic queries PR on current master
@anmonteiro: thanks!
@dnolen: thanks for merging #638! I think it'd be ideal to find a way that we don't retrigger a render ever on unmount, if we could update :om.next/queries
without triggering the watch on the state. I couldn't think of a way though
@jlongster: there’s probably a hack-ish way to make it work, will ponder it later
cool, I can file an issue as a reminder, I may think about it at some point if it's not done by then
I'm also working on the path-meta
optimizations right now, it's the last part that's slow in my app
@dnolen: @jlongster: that won't be an issue once we move queries from the app-state
will also help people trying to set-query!
when using datascript
@anmonteiro: ah right
not sure when you want that to happen though
I think it would be feasible to do it right after the dynamic queries stuff
I also thought of a situation that might be buggy right now: imagine a component tree A->B->C. A pulls a query off of C and passes down the data through B. Then C uses set-query!
to change the query params and it gets new data. Then B is rerendered because of a set-state!
call on it, and it passes down the old props to C, right?