Why not create new observables in computeds?

[martinslota]

I'm trying to understand the reason behind the second rule of computeds: Why is it a bad idea to create an observable from a @computed getter? Is there an actual technical limitation, or is this more of a soft rule that helps avoiding shooting oneself in the foot? If it's the latter, what are the most common complications arising from doing it anyway?

For example, if there is a need to make an HTTP request whenever a specific selection changes, is this really wrong to do?

import { computed, makeObservable, observable } from 'mobx';
import type { IPromiseBasedObservable } from 'mobx-utils';
import { fromPromise } from 'mobx-utils';

class Store {
  @observable selectedItemId: string = 'item1';

  constructor() {
    makeObservable(this);
  }

  @computed
  get name(): IPromiseBasedObservable<string> {
    return fromPromise(fetchItemName(this.selectedItemId));
  }
}

async function fetchItemName(id: string): Promise<string> {
  return 'bob'; // or actually fetch the name asynchronously from somewhere
}

[kubk]

A computed is a pure function that depends on observables. It shouldn't have side effects to remain pure. I'd complete the task in this way:

class Store {
  @observable selectedItemId: string = 'item1';
  @observable name?: IPromiseBasedObservable<string>;

  constructor() {
    makeObservable(this);
  }
  
  @action selectItem(itemId: string) {
    this.selectedItemId = itemId;
    this.name = fromPromise(fetchItemName(this.selectedItemId))
  }
}

[martinslota]

Thanks, your suggestion makes a lot of sense for my contrived example.

What I'm trying to get at, though, is the why behind the rule.

A computed is a pure function that depends on observables. It shouldn't have side effects to remain pure.

So is creating a new observable a side-effect? How so?

[urugator]

Computed (arguably) represents data that can be derived/reconstructed from your state at any point in time - the cache is just an optimization, not something to design your system around.
You should assume that accessing name 3 times will result in a creation of 3 promises. With this reasoning it doesn't make sense to return anything statefull and therefore observable.
This is because the cache dependents on usage - you assume that your class is used in a particular way, but from the consumer point of view, it's just a field/value as any another.
Eg, in react's concurrent mode, the field can be read during render multiple times, but the component may not ever get committed, so the fetch results are just thrown away.
The situation is a bit different with keepAlive option, however there are still things to consider:
If you create and return new observable, you're likely returning something that's potentially non-trivial to recreate and non-trivial to compare (object/array/...), eg:

@computed({ keepAlive: true })
get derivedStore() {
  return new DerivedStore({ dependency: this.dependency })
}

Does it make sense to loose whole state and subscriptions associated with DerivedState instance, when this.dependency changes? You usually want to only update the derivedState.depedency and (arguably) the best place to do that is in action that changes this.depedency.
You can also provide custom equals, but that may be non-trivial to implement and incurs overhead (recreation + comparison) often making computed completely useless.
Another question you may ask is whether getters in general should contain side effects - they may "neatly" hide a complexity (lazy loading) or reduce some boilerplate, but from my experience it's just unexpected and confusing.
(Creating observable is not a side effect, but in your example the side effect is basically the reason for returning new observable).

Technically nothing's gonna break, doesn't matter whether the returned thing is observbale or not. It's just a matter of whether it makes sense or not. Lots of people actually does this.

[martinslota]

Many thanks! This really helps me understand the trade-off and make relevant decisions.

Would it make sense to add some of these details into the documentation? As you say, people do seem to take this kind of approach and rely heavily on the caching built into @computed, though that is perhaps not quite its intended use. I could try to help with writing this up, if you think that makes any sense.

[urugator]

I should point out I am not an author of that statement in docs, I don't know what the exact intended reasoning was.
I know there are mobx veterans, that disagree with me about many things, so I would prefer leaving this on someone else :)