In the past destructuring was discouraged, is this still the case?

[rluvaton]

In the past destructuring was discouraged, is this still the case?

Don't destructure
MobX observables are objects only. When destructuring, any primitive variables will remain at latest values and won't be observable anymore. Use boxed observables to track primitive values exclusively or preferrably pass a whole state object around.

From the deprecated https://mobx-react.js.org/state-destruct

However, now it doesn't state that, and in Understanding reactivity it says that destructured values are tracked:

At that point it is invaluable to understand how MobX determines what to react to.

MobX reacts to any existing observable property that is read during the execution of a tracked function.

"reading" is dereferencing an object's property, which can be done through "dotting into" it (eg. user.name) or using the bracket notation (eg. user['name'], todos[3]) or destructuring (eg. const {name} = user).

[kubk]

Destructuring should work with no issues. I don't understand why it was discouraged before. Maybe because Mobx didn't use ES6 Proxy in the past?

[urugator]

Destructuring was always fine. It's more about dereferencing late:
https://mobx.js.org/react-optimizations.html#dereference-values-late
https://mobx-react.js.org/ was more or less a personal project of mobx-react-lite's original author FredyC.
It's just an unfortunate choice of words combined with opinionated usage patterns.

[rluvaton]

Thanks!

[qwertie]

Note: the linked page says that instead of

<DisplayName name={person.name} />

you should write

<DisplayName person={person} />

But presumably, DisplayName doesn't need a person, it needs a string, so it shouldn't have a parameter of type Person, although a parameter of type { name: string } would be okay. Most of the time, I would recommend a function parameter instead:

<DisplayName name={() => person.name}/>

This accomplishes the "dereference late" goal without giving the child component more stuff than it needs.

Edit: I guess I spoke too soon, as the next section ends up recommending this:

const GenericNameDisplayer = observer(({ getName }) => <DisplayName name={getName()} />)

This seems to be based on an assumption that you don't want to change the DisplayName component, which may or may not be a reasonable assumption. My inclination is simply to define DisplayName as

const DisplayName = observer(function DisplayName(p: { name(): string }) {
    ...
});

[urugator]

While you gain the benefit of re-rendering only DisplayName when only name changes, you loose the ability to re-render only parent without re-rendering DisplayName, because the inlined callback is different with each render, therefore breaks memo of DisplayName. You would have to memoize the callback, which isn't really worth it. If you need a generic component depending on a primitive, just use the primitive. Keep it simple. Do not optimize until you need it.

EDIT: I don't suggest to do so, but you could wrap all primitives in you models in extra box and then all the components should accept { get(): T } instead of primitives. I guess you could make an eslint plugin for that.
EDIT: However, it just occured to me, internally, such box already exists, maybe it would be cool to provide something like getBox(obj, 'name').
EDIT: Actually you can do it already in user land, create the getter function lazily in getBox and cache it on the object...

[Besuf]

It is true destructuring perfectly works for observables. However I get uncaught exception every time when I try to use destructured actions. I haven't also seen places where destrucutured actions were used in the doc examples. It'd be helpful If someone explain why this is so

[kubk]

@Besuf It's probably due to your actions aren't bound hence losing this. You can fix it by replacing makeAutoObservable(this) with makeAutoObservable(this, {}, { autoBind: true })

[Besuf]

I can verify this works. Thanks for the explanation :)

[goamn]

This is great thanks :)