Avoid om.core.join using IEquiv to compare cursors in shouldComponentUpdate about om

[swannodette]

The point about IEquiv over identical? in shouldComponentUpdate is solid and one I've been pondering myself for a while. I'm not sure that something like om.core/join is problematic, in anycase it's orthogonal to benefits delivered by relying on IEquiv. I will think about it some more.

[swannodette]

shouldComponentUpdate fixed to use not= in master, ed99bf2. If you think about the use case where the application state is laid out more like a database and not like a UI tree I think you'll see that om.core/join or something like it is really not such a bad idea. Thanks for the feedback.

[swannodette]

Just to keep this up-to-date. I've reverted the IEquiv change in master. Relying on IEquiv is currently problematic since you can nest Om components that use the exact same piece of data. If you call om.core/set-state! further down then we can not determine the invalidated path.

I think I realized this at some point and that's why we weren't using IEquiv.