Fork me on GitHub

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)
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.


Is there any demo for server push with


@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 wasn't componentWillReceiveProps meant for doing this kind of updates?


I am using om/transact! [('server/message ...)], anything wrong with that?


@sander: Ah. missed that one. I’ll try that, thanks.


@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.


Might not be the best design but it's working well for my force layout


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


so (om/transact! reconciler '[(server/message ...)])


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..


but am not sure if I'm using transact as intended


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, it doesn’t override shouldComponentUpdate either.


released alpha31


@dnolen: rebased latest dynamic queries PR on current master


@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 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


a bit mind-bending but I think I'm figuring it out


@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


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?


same issue as why we can't avoid running queries when calling set-state! like I tried before


but set-state! doesn't trigger re-running queries because B has no queries