Request for code review for a MobX port

[slimshader]

Hi,

as a learning exercise I ported this React/MobX blog example to UniMob/Unity/UI Builder:

blog:
https://hackernoon.com/how-to-decouple-state-and-ui-a-k-a-you-dont-need-componentwillmount-cc90b787aa37

port:

https://github.com/slimshader/state-routing-blog-unity

in addition for it to hopefully it could be help to others, I'd love if someone could take a look and comment on my version.

note: obvious difference from original (React) is lack of the Components so VisualEments are reused by showing/hiding

[vanifatovvlad]

your repository is private

[slimshader]

sorry, fixed

[slimshader]

Hey, did you had a chance to take a look?

[vanifatovvlad]

I have looked at the project. It took some time to figure it out, since I'm new to the ui toolkit.

In your code, there is a LifetimeVisualElement class that creates a LifetimeController. You must call the Dispose method for all controllers, otherwise atoms with these lifetime will never be stopped. I prefer to use approach when dispose method always called by the same script that creates the lifetime controller. However, visual elements don't have an explicit destruction point, so it's not a good idea to use lifetime on them.

Also in the original example uses not only MobX but also MobX-react and MobX-utils. An analogue of MobX-react is UniMob.UI, but it uses UGUI and not ui toolkit. And there is no analogue of MobX-utils now. So recreating the sample from the article while retaining all the ideas (such as generating UI as small pure functions based on state or use network requests as atoms) is quite problematic.

I tried to reproduce all this in my repository. however this is just a demo, serious improvements are still required to use this approach in real projects

[slimshader]

Fantastic, looking through your code right now. I noticed usage of "Atom.NoWatch", is there more info on its usage somewhere?

[vanifatovvlad]

Reactions and computed atoms by default subscribes to all atoms that were accesed during the value calculation. But sometimes we want to read values and not subscribe to their changes. For example, the Build method can be called inside a reaction. However, the BuildTree method is called inside, which theoretically can read other atoms, but we do not want the reaction to be updated when they are changed. Therefore, at the beginning of the Build method, a NoWatch is called that blocks the subscription

[slimshader]

I see, makes sense. I think I am getting most of the code now but have few more questions:

1. what does making this atom help with: Atom
2. is there away to access list of all atoms (roots) for debug purposes (and possibly draw graph in unity editor using debugNames)
3. is it possible to manually control Atom update cycles?

[vanifatovvlad]

1. sources is a function that is invoked in the bind callback, which executed during scrolling every time a new element becomes visible on the screen. So the value will be calculated many times. The sources function in the demo simply reads the data, but in real projects it can generate data, for example, Render(() => someList.Where(it => it.Visible).ToList()). Therefore, it is good practice to wrap the function in an atom that caches the value once and uses cached data next
2. UniMob has simple debugger window which displays all active atoms
3. No. Reactions are executed either on the next frame by AtomScheduler, or when the Actualize method is called. Atoms are updated when data is read from them