Remove Evt.asPostable(evt)

[andreas-wagner]

What is the problem?

Let's see the docs

Use this method only onEvt you instantiated yourself. Not as a hack to trigger events on Evt that have been exposed as non-postable by an API.

..and the source-code

export function asPostable<E extends NonPostableEvtLike<any>>(evt: E): ToPostableEvt<E>{
   return evt as any;
}

This means everyone can post on any Evt instance, being the creator or not.

Let's assume we have a service providing some evt's, and the service is controlled by some part of the application.
This part of the application gives these evt's to other parts.

Example:

A file logger has to close a file handle on evtServiceShutdown, but the logger is part of some other external module.
That external module is not used all the time and instantiated and destroyed multiple times during the services lifetime.
Maybe it's only used once a day to synchronize with something.

Now if the logger posts on the evtServiceShutdown the whole service shuts down. This is bad. It should not have any ability (in real js, not ts) to post to evtServiceShutdown.

Proposal

Create a fully functional Evt instance first, and from that create a new NonPostableEvt instance that can only listen to it's parent(s) and does not have any post method.

Somehow deno std logger comes to mind, with separated handlers and formatters and the logger instance being modular.

class Example {
  #evtMsg = new Evt<string>();
  public readonly evtMsg: NonPostableEvt<string>;

  constructor() {
    evtMsg = this.#evtMsg.createListener(); // we only want to publish something, where users can listen to in various ways
  }
}

[garronej]

Thanks @andreas-wagner,

Thanks for the feedback. I am not happy about Evt.toPostable() either.
So what you are suggesting is to remove Evt.toPostable() and to encourage this way of doing things instead?

import { Evt } from "evt";
import type { NonPostableEvt } from "evt";  

class Example {
  #evtMsg = Evt.create<string>();
  readonly evtMsg= Evt.asNonPostable(this.#evtMsg);

  constructor() {}
}

This is nice! Using # makes it work well (I didn't exist back then and I moved away from OOP 2 years ago)

[garronej]

After futher consideration I think it is best that if Example.prototype.evtMsg is a distinct event instance.

import { Evt } from "evt";
import type { NonPostableEvt } from "evt";  

class Example {
 #evtMsg = Evt.create<string>();
 readonly evtMsg= Evt.asNonPostable(this.#evtMsg.pipe());

 constructor() {}
}

This way even if a user try to (example.evtMsg as any).post("foo") it won't mess up our internal Evt instance.
An external use of example.evtMsg.attachExtract(message=> { ... }); could also end up messing up the internal working of the Example class.

Evt.asNonPostable() isn't problematic since an Evt<T> is assignable to an NonPostableEvt<T>.

So, I agree to remove Evt. asPostable() but for now I will just deprecate it since I don't want to release a new major just for it.

[garronej]

I have updated the documentation:
https://docs.evt.land/migrating_from_events#composition-recommended-approach

[garronej]

And I released 2.4 where Evt.toPostable() is deprecated.