Misleading documentation on destructuring compted properties

Hey guys,

First of all, thank you very much for the great library!

I must caveat this is 100% nit, but maybe you will find it useful to correct – happy to provide a docs PR if you suggest so.

I have been playing around with various aspects of it and noticed that the docs at https://easy-peasy.dev/docs/api/computed.html#computed-properties-break-when-destructuring-a-computed-property-out-of-state, although being correct in general, provide an example that actually is not flawed.

The thing is that when a computed property getter is pure and depends solely on the sub-state it’s defined in (just like in the example where isLoggedIn only changes when user of session sub-model changes), the deconstruction will work just fine. The comparison function in useStoreState will receive the whole sub-model state, will notice it changed and will trigger a re-render, leading to computed property working correctly.

What will break though is if a computed property is impure w.r.t to the sub-model it’s defined in (e.g. depends on another sub-model). It’s not straightforward to achieve (the default use of computed helper supplies local state only), but of course possible when state resolver is involved:

const storeModel = {
  user: {
    current: null,
  },
  session: {
    isLoggedIn: computed((_, storeState) => [storeState.user], (userState) => userState.current != null),
  },
};

The reason I am writing about this at all is because it’s very convenient to use the deconstruction in certain cases and it’s a pity the documentation effectively bans that for computed property – but I appreciate it might be perceived easier than mentioning specific conditions under which it is ok or not ok.

[yard]

Yeah that makes sense, let me write it up 😃

[jmyrland]

Thanks again!👏