Enable third-party annotations

[norami]

One of the factors that determine the evaluation of the library is the ecosystem of third-party libraries. So I'm developing libraries including mobx-async-computed because I love the concept of MobX.

However, MobX6 doesn't provide an official way to create a third-party annotation.

https://github.com/honeysol/mobx-library/blob/2c45209e047a39ebfd85546805b252accbb09143/packages/mobx-annotation-manipulator/src/mobxInternalSymbol.ts

While I'm exploiting the terrible hack to obtain the Symbol(mobx-stored-annotations) shown in the link above, needless to say, this is vulnerable and undesirable.

I propose to publish two internal methods :

storeAnnotation
recordAnnotationApplied

Or to introduce a new API to create an annotation in the way like this source code

I believe this change makes MobX more powerful and helps it to involve many people.

[urugator]

They way annotations/decorators are implemented is different in 5.x, 6.0, 6.1 and will probably change again in 6.2.
In order to implement something interesting you need to have an access to other internal APIs (like administration object), that are also unstable.
Implementing annotation correctly is non trivial, eg. atm make_/extend_ must behave the same for plain object, must handle interceptors/observers correctly, must work correctly with (sub)classes, etc.
It would be quite diffucult to support this in a reasonable way.

[mweststrate]

Composable annotations / decorators are a problem that should imho be (and are being: https://github.com/tc39/proposal-decorators) addressed at a language level, rather than at MobX level. Our current implementation of annotating / decorating things are a stop gap for which our primary concern at this point is making sure we are compatible when official decorators ship. So shipping a competing implementation in the mean-time isn't really among our goals, instead we're involved in the progress of said proposal.

…

On Wed, Mar 17, 2021 at 10:28 AM urugator ***@***.***> wrote: They way annotations/decorators are implemented is different in 5.x, 6.0, 6.1 and will probably change again in 6.2 <https://github.com/mobxjs/mobx/pull/2806/files>. In order to implement something interesting you need to have an access to other internal APIs (like administration object), that are also unstable. Implementing annotation correctly is non trivial, eg. atm make_/extend_ must behave the same for plain object, must handle interceptors/observers correctly, must work correctly with (sub)classes, etc. It would quite diffuclt to support this in a reasonable way. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2856 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBAVBRDC3OMU6PJ3JDDTEB73DANCNFSM4ZJ3SGNA> .

[norami]

@mweststrate
@urugator

Thank you. I recognize publishing storeAnnotation/recordAnnotationApplied is not a good idea. It depends on MobX internal implements too deeply and too vulnerable to publish. But, that's why API like createAnnotation is required to encapsulate the transition of MobX internal implementation and JavaScript decorator API.

As we all know, MobX itself is independent of decorator/annotation. And more, we all can create a new library using MobX easily. Decorator/annotation should be an additional feature and the thin and public wrapper of MobX core API functionality, instead of the complexity of the implementation.

If some of the maintainers agree with me, I'm ready to make a pull-request about this problem.

[mweststrate]

We have rewritten the darn thing already three times, which was already terribly complicated without thinking about generic unknown consumers. So, rather not :). MobX isn't a generic object manipulation library. Generalizing this is terribly complex once you factor in all relevant language constructs like prototypes, static, shadowing, intializers and initialization order, as the fact that the proposal is running for 5 years proves. So I'm highly skeptical. That doesn't exclude it isn't possible, but if such a thing is done, consider it is then also possible to reverse the problem: build a generic decorator / annotation / object manipulation lib, and base MobX on it :) In the meantime I recommend to build own utilities that manipulate specific fields (e.g. makeFieldAsyncComputed(this, 'there')) rather than repurposing MobX internal infra. By the way so far it is unclear to me why you are needing the MobX symbols in the first place? We have reflection utilities like isComputed and getAtom in place to find the backing atoms of a certain field.

…

On Fri, Mar 19, 2021 at 9:22 AM norami ***@***.***> wrote: @mweststrate <https://github.com/mweststrate> @urugator <https://github.com/urugator> Thank you. I recognize publishing storeAnnotation/recordAnnotationApplied is not a good idea. It depends on MobX internal implements too deeply and too vulnerable to publish. But, that's why API like createAnnotation is required to encapsulate the transition of MobX internal implementation and JavaScript decorator API. As we all know, MobX itself is independent of decorator/annotation. And more, we all can create a new library using MobX easily. Decorator/annotation should be an additional feature and the thin and public wrapper of MobX core API functionality, instead of the complexity of the implementation. If some of the maintainers agree with me, I'm ready to make a pull-request about this problem. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2856 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBBIR6W2ON5LR6UAY6DTEMJUHANCNFSM4ZJ3SGNA> .