Documentation and ESLint inconsistencies

[webcodion]

Hi!

Thank you for this great library. I've read your documentation over and over again while refactoring my code. However, some things are still unclear to me regarding this sentence:
"deps in useEffect should be used extracting primitive values from state const { num, string, bool } = snap.watchObj or (not preferred) with [snap.num, snap.string, snap.bool] directly (less stable)."

1. "extracting primitive values from state" sounds to me like: const { num } = state; shouldn't it be "...from snapshot"?
   Because if I do this

  const { num } = state;

it logically doesn't trigger re-render (as expected #transient).

2. What exactly does "less stable" mean? What do I have to watch out for?

3. According to your note on useEffect() and to my understanding, this should be the correct way of utilizing useMemo(), right? (This is of course a simplified example. And yes, I'm aware I should only be passing primitive values as dependencies, however, the warnings mentioned below occur either way.)

const store = proxy({
  machineConfig: []
});
const snap = useSnapshot(store);
const { machineConfig } = snap;

const machines = useMemo(() => {
  const data = [];
  for (const machine of store.machineConfig) {
    data.push(machine);
  }
  return data;
}, [machineConfig]);

Now, React linting will tell me to remove machineConfig because it's not used. If I try to use machineConfig inside useMemo, then your linting will warn me to use proxy state instead (state-snapshot-rule). So, whichever I choose, I get a warning. Is this intended, should I just ignore it or am I using it the wrong way? I do NOT get the React warning when I use useEffect() for some reason...but I still get the one regarding state-snapshot-rule.

I read the part on React.memo(), though. Does this apply to useMemo() as well?

4. Maybe you could add a useEffect() and useMemo() example to your documentation? I'm having a hard time finding examples on the web.

I hope this is clear to you, thank you so much in advance!!

Alex

[dai-shi]

shouldn't it be "...from snapshot"?

Oh, yes! You are right.

What do I have to watch out for?

Hm, good point. [obj.a, obj.b] in deps is not preferred in React in general, because it can be changed? (I guess eslint rules warn this, but maybe it's improved?)
But in valtiosnap is a frozen object, so there would be no pitfalls.

const machines = useMemo(() => { ... }, [machineConfig])

There's a pitfall with this usage. If you touch machineConfig.foo in the same render function. It will not work as expected.

add a useEffect() and useMemo() example to your documentation

Yeah, that's a valid suggestion.
But, not sure what to suggest for certain.
The recommended pattern for useEffect is:

useEffect(() => {
  // ...
  const unsub = subscribe(state, () => { ... })
  // ...
  return unsub
}, [..., /* no proxy state nor snap here */])

For useMemo, I'd avoid using it with state/snap objects. Only with primitive values.

I'd want more feedback on these.

[webcodion]

Thank you!

[webcodion]

Oh one more thing:
In React, there's useEffect() and useLayoutEffect() -> when I use subscribe(), will it work as expected in both cases?

[webcodion]

Furthermore, it would be great to be able to use subscribe() on an object which is null on init. Currently, this will throw an error.

[webcodion]

A final question:

How to use subscribe/subscribeKey with props?
subscribeKey(props,` 'value', ...)
isn't working. Neither is subscribe(props, ...).

AND

How can I have subscribe trigger on obj reference change? -> subscribe(state.x, ... -> then re-assign x to another value -> or is this not possible at all? useEffect() does trigger as expected, however.

[dai-shi]

In React, there's useEffect() and useLayoutEffect() -> when I use subscribe(), will it work as expected in both cases?

Yes.

it would be great to be able to use subscribe() on an object which is null on init.

That's not technically possible. Consider wrapping it with another object.

How can I have subscribe trigger on obj reference change?

Again, not possible by nature. Subscribe on parent or re-subscribe on your end.