That walkable logo is great. Hahah

The canvas example in the fulcro book is very useful for me, the rerendering is very smooth on that sample. I'm currently drawing starcraft II output to a canvas. And planning to implement mouse functionality (so clicking/dragging boxes etc), I hope I can get it as smooth as that.

Currently the rendering is still too slow for that to be useful though. I'm doing some ugly conversions of a bytestring to a binary string and then sometimes back to an 32byte arraybuffer. Sigh. Working with binary data in JS is blegh.

It seems having :ref on a component triggers the render function on a constant (requestAnimationFrame?) basis, even if shouldComponentUpdate is passed false. I guess that's intended and I should put the expensive binary conversion in the model.

I noticed because chrome canary spammingly warns the raf handlers take too long.

@bbss having a ref doesn't do that, having a ref that is a lambda is probably your culprit, since a new lambda is generated every time, and that changes the props that are seen, which makes it refresh when it doesn't need it. Generating the lambda on mount and storing it as a prop on the instance is one way around that.

Oh wow.. I might be making that mistake on my JS projects at work too. Although maybe it could be a om/fulcro thing "props that are seen". Thanks for the insight.

it's a general react thing...if any prop changes it has to update the DOM

Okay, keeping an eye out for that then 🙂

Moving the binary conversion to the push-handler did improve things 🙂. I guess if it was a load/read that I got the data from I would be using the the post-mutation for the same thing.

usually in JS I use redux which would wire up the callbacks in the connect method