CLJS data structures are compared by ref in <-effect deps about hx HOT 11 CLOSED

I’ve commented on that react issue as pointed by Roman in Twitter:
https://twitter.com/roman01la/status/1107695745493356545

facebook/react#14476

Some similar efforts to bridge Hooks and ClojureScript are here:
https://github.com/mhuebert/chia/blob/master/view/src/chia/view/hooks.cljs

from hx.

Solution is to capture deps in a ref and do the equality check in clojure, pass result to React

from hx.

Fixed via ba0d520

from hx.

I was just reading up on this, came to post about it :)

Doesn’t useState have the same issue? React will skip the render if the returned value is the same as the previous one, but it uses the same algorithm.

from hx.

Ah, I didn’t think to check useState as well. Good call out!

I wonder if there is a good way to handle that... I’m not sure how to do the comparison if the value given to the update function is itself a function to be applied, without doing the computation twice.

And using a ref we might end up creating similar bugs as with atomified <-state.

from hx.

Hello! Do you have any ideas how this can be fixed for useState? I'm starting to think that Hooks API stands in the way of integrating React with ClojureScript when trying to provide idiomatic Clojure API for library users.

Including @mhuebert in this discussion, since he's working on a wrapper as well.

from hx.

I don't have any specific thoughts in mind yet. I am working though on a real-world application that's built entirely on hx, so I'm using that as a real-life place to validate new ideas.

The thing that is really great with hooks though is that the API surface is rather small, so it's easy to write different wrappers and see how they behave. Their composability is what makes me want to keep pushing this, since doing the same with class-based components was pretty much impossible.

from hx.

Actually I think this is an easy fix for useState, if you wrap the hook you can compare values inside of the wrapper before setting a new value onto the hook roman01la/uix@3665c63

from hx.

Yeah, that's the obvious fix. We discussed at length with @Lokeh whether it makes sense to expose the "ref" semantics of atoms, because they can be confusing if you're expecting normal clojure atom behaviour. See #11 (comment)

from hx.

   (when (not= new-value value)
    (set-value new-value))

I was trying to think of values for which Clojure would say not= while Object.is would say true (ie. cases where set-value would be an undesired no-op), but the only thing I could think of is js/NaN, which is probably not an edge case to worry about.

from hx.

I think that's a very good point and a test suite could be setup to explore this. If it's only js/NaN then perhaps it's not worth the hassle :)

from hx.