Prefer using react api for useProperty hook

[raveclassic]

Prefer using react api for useProperty hook

[raveclassic]

Hey @PalmZE, thanks for such a detailed issue!

So, correct me if I'm wrong, the issue is that during rendering of list items that reference list values in Properties by index, we can get out of sync with the data because this list item component is not unmount in time, right? This happens due to asynchronous nature of the renderer, right? Then I would expect such components reading the data by index to check whether the item is not undefined. That would be the correct behavior to work with changing lists and "stale" indexes. By "stale" I mean that they might get out of sync due to async rendering in React. That's a common problem actually and it's not related to setting the state in the render cycle. The wrong index, captured during rendering of the list, might reference non-existing item anyway, as the rendering most of the times is out of sync with the data (especially taking React's Concurrent Mode into account). So, in short, I would say it's the responsibility of the UI composition to write to/read from Atom/Property correctly.

Originally, @frp-ts/core was design to be fully synchronous at its heart, so although most and other libs implement asynchronous value delivery (microtasks for example), I'm not sure whether it's a good option to adopt similar concept here. At the end of the day, it's not the responsibility of Atom to think about how/when the value should be delivered to its consumers, but of the caller of Atom#set. In most cases, synchronous emission is enough, in some cases (like with React) it may break things but we should think about such cases outside of the core. For example, it's fine to tackle this in @frp-ts/react.

Ok, now speaking about @frp-ts/react, honestly I don't know wtf is use-subscription/``use-mutable-source` or any other fancy APIs they are going to bake into the core :D. But, seems until it's not in the core, we are free to ignore it. At the same time, I think it's fine to think about improving existing bindings to React if there are any issues with them.

Thanks for opening the issue and let's continue the discussion here.

[PalmZE]

So, in short, I would say it's the responsibility of the UI composition to write to/read from Atom/Property correctly.

I thought a bit more about the issue, and I agree.

At the same time, I think it's fine to think about improving existing bindings to React if there are any issues with them.

Existing bindings are working fine. This is an approach similar to other libraries (mobx, effector, etc).

I created this issue to discuss the possibility of using useSyncExternalStore since it simplifies the usage of atom-like sources. But, I agree that until this api is in the core (and React 18 is released) current version is safer.

I'll test useSyncExternalStore in my own project. Can let you know, if it works ok in the long run.

---

Conclusion: I have nothing to add, feel free to close this issue.

[raveclassic]

Thanks for the feedback @PalmZE. Closing.