Is it different from MobX?

I just found a comment by @FredyC in https://github.com/facebook/react/issues/15156#issuecomment-511097919.

@fuleinist Ultimately, it’s not that different from MobX, although a lot simplified for a specific use case. MobX already works like that (also using Proxies), the state is mutated and components who use specific bits of the state get re-rendered, nothing else.

I’m not very familiar with MobX, so please correct me if I’m wrong. As far as I understand, MobX uses Proxies to trap object mutations, not object property access in render function. I mean, what it’s providing is not an alternative to Redux/ReactHooks reducers. Theoretically, MobX is complementary to react-tracked. I’m not yet sure if/how it can be implemented, though. react-tracked doesn’t change the semantics of render function. It tracks the state usage and trigger re-renders. How to update state is not the focus of the library (at least at the moment).

I wrote an example to show the power of state usage tracking in the “Advanced Example” in https://blog.axlight.com/posts/effortless-render-optimization-with-state-usage-tracking-with-react-hooks/.

---

(edit) There was a misunderstanding of mine. useObserver tracks the state usage.

[mweststrate]

Super cool project!

I’d have to tinker about this a bit more, but yes, I think this could potentially be useful for a completely alternative api to observer. The problem I was running into so from being able to say just useObserver(), is that we could already implement starting tracking for the current component, we just didn’t have a means to reliably end tracking for the current component. (Not fully sure that is unsolvable, but didn’t see a solution yet).

So this solution to create a proxy (if I understood it correctly from the source) per render, so that we every read an be traced back to the owning component solves that problem (granted, one has to has proxies).

On Mon, Aug 5, 2019 at 7:06 PM Daniel K. [e-mail] wrote:

Uh…wow? 😃 You know, we were kinda fighting initially with this problem of needing observer around what’s being rendered to keep track of it. What’s the most surprising that it doesn’t actually re-render more than necessary. Just for a convenience a modified version which logs renderings.

https://codesandbox.io/s/peaceful-swartz-cn280

@mweststrate https://github.com/mweststrate Sorry, but I have to ping you in here, you have to see this 😃 ☝️

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dai-shi/react-tracked/issues/7?email_source=notifications&email_token=AAN4NBHF6BRNVGF7JG6NFMDQDBMYVA5CNFSM4IJLUHAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3SOL6Q#issuecomment-518317562, or mute the thread https://github.com/notifications/unsubscribe-auth/AAN4NBD6BWTYEOIQGDJZQQTQDBMYVANCNFSM4IJLUHAA .

[danielkcz]

react-tracked is so tied to react local state and the state is updated immutably. So, I can’t simply use the bare Provider/useContext which would trigger all consumer components to re-render.

Makes sense. That’s what so great about MobX, because it has stores with stable reference, the Provider won’t even re-render in most cases. Only components accessing variables that have actually changed will render.

Recently, I wanted to use Formik V2, but there are so many issues related to immutability and that everything is recreated on each keystroke. I ended up writing my own form solution based on MobX and it’s awesome. It’s not for public consumption though (yet). I even wrote an article about it some time ago … https://levelup.gitconnected.com/formik-with-react-hooks-and-mobx-1493b5fd607e

That selector hook is definitely useful for immutable state, but in case of MobX not so much 😃

About your experiment, that’s something that I am afraid of too even for MobX, because useLocalStore might suffer there. The mobx-react-lite@next basically takes care of proper cleanup of reactions that were never committed, but it doesn’t solve a problem of local states.