Expose isAnnotatedField function (that uses storedAnnotationsSymbol)

[mnieber]

I have a use-case where (before makeObservable is called) I want to add annotations to fields unless if they are already annotated. I see in the mobx code that access to storedAnnotationsSymbol would make this possible.

Could this symbol be exposed? Or alternatively, could you add a function that allows me to get the existing annotation (if any) for a given field?

[kubk]

There are already exposed helper functions like isComputed / isComputedProp, isAction, isObservable / isObservable*. Would they work?

[mnieber]

AFAIK these helpers tell you if the property is observable after makeObservable has already been called. In my case I would like to know if the property has been annotated (because I will programmatically add more annotations and then call makeObservable).

[urugator]

You can call makeObservable as many times as you want as long as you annotate different fields.
So you can call makeObservable, then inspect fields with isObservableProp etc, then call it again with other fields.
storedAnnotationsSymbol is an implementation detail and is only concerned about processing decorators. It would be fragile to rely on it.
Object.gerPrototypeOf(this)[storedAnnotationsSymbol] returns annotations coming from all decorators from the whole prototype chain.
this[storedAnnotationsSymbol] returns only these that weren't applied yet (it shrinks with each subclass constructor).

[mnieber]

Hi @urugator, the point you raise about annotating different fields is exactly the crux. I would like to programmatically add more annotations, but only to fields that have not yet been annotated. The problem is that afaict there is no way (yet) to tell if the field has been annotated or not.

[urugator]

const isAnnotated = key => isObservableProp(this, key) || isComputedProp(this, key) || isAction(this.key) || isFlow(this.key);

makeObservable(this) // apply decorators

if (!isAnnotated("something")) {
  makeObservable(this, {
    something: observable,
  })
}

??

[mnieber]

I think this would work, because I now remember that I used this approach before. I tried to move away from this because I didn't like the multiple calls to makeObservable. I wanted to first set up the annotations, and then call makeObservable once (also with the idea in mind that maybe in the future the place for setting up the annotations might not be the place where makeObservable is called). But maybe this is too much of an edge-case? In any case, thanks for you help, I have a better understanding now.

[urugator]

You could also create your own decorators, that just delegates to mobx's decorators, but adds some metadata to prototype (similar to storedAnnotationsSymbol) that you can inspect later.

[mnieber]

Actually, I have my own decorators, but I leave it open whether using my delegator also implies using the mobx delegator. Let me quickly explain with an example:

export class Selection<ValueT = any> {
  @input selectableIds: Array<string> = stub();
  @data ids: Array<string> = [];
  @data anchorId?: string;
  @output items: Array<ValueT> = stub();

  @operation selectItem(selectionParams: SelectionParamsT) {  ... details omitted ... }
}

This defines an abstract Selection behaviour that lives in a container object that may also have a Highlight, Filtering, DragAndDrop, etc (these behaviours work together). If you call registerCtr(container) then every @data field is converted into an @observable field. But this conversion only happens if the project is using MobX (that's why I say that "I leave it open").

All this works fine, but if the user mistakenly writes something like @data @observable selectableIds: Array<string> = stub(); then it breaks down. This is why I would like to detect existing annotations.

In any case, like I said, things are clear. The "double annotation" is an edge case I can work around with your solution.

[urugator]

If I follow correctly, since mobx is optional, your code doesn't depend on "observability". Why don't you leave making @data field observable up to user?

Generally we don't support combining mobx's decorators with others. Not sure what @data does by itself, but I think you can simply:

export function data(target, property) {
  /* 
    ... whatever @data does ...
  */
  // Apply mobx's observable
  mobx?.observable(target, property)
}

Either you would leave calling makeObservable up to the user or as long as you're in in control of instance creation you can call it yourself (however it will throw if there are no @data fields).
@data @observable would throw: https://github.com/mobxjs/mobx/blob/main/packages/mobx/src/api/decorators.ts#L37

Note the end user could do the same, just exposing it's own @data decorator combining your @data with @observable:

export function dataAndObservable(target, property) {
  data(target, property)
  mobx.observable(target, property)
}

Another way would be to rely on emitDecoratorMetadata

[mnieber]

You are correct that the code for abstract behaviours doesn't depend on observability. It's agnostic of MobX, which means that there is no mobx?.observable in the code. It has a default registerCtr that only sets up some logging of the container (also based on @data). To support MobX I offer a special version of registerCtr (that lives in a separate library) that invokes MobX.