← Back to context

Comment by arnorhs

3 days ago

I'm not a huge fan of using CustomEvent for this.. esp. in terms of interoperability (which for these <kb challenges probably doesnt matter)

personally, i'll just roll with something like this which also is typed etc:

    export function createPubSub<T extends readonly any[]>() {
      const l = new Set<(...args: T) => void>()

      return {
        pub: (...args: T) => l.forEach((f) => f(...args)),
        sub: (f: (...args: T) => void) => l.add(f) && (() => l.delete(f)),
      }
    }

    // usage:
    const greetings = createPubSub<[string]>()
    const unsubscribe = greetings.sub((name) => {
      console.log('hi there', name)
    })
    greetings.pub('Dudeman')
    unsubscribe()

10 comments

arnorhs

Reply
Joeri  3 days ago

If listeners of this implementation aren’t unsubscribed they can’t be garbage collected, and in a real world codebase that means memory leaks are inevitable. EventDispatcher has weak refs to its listeners, so it doesn’t have this problem.

  • AgentME  3 days ago

    The listeners can be garbage-collected if the `greetings` publisher object and any unsubscribe callbacks are garbage-collectable. This is consistent with normal Javascript EventTargets which don't use weak refs.

    If only weak refs were kept to listeners, then any listeners you don't plan to unsubscribe and don't keep that callback around will effectively auto-unsubscribe themselves. If this was done and you called `greetings.sub((name) => console.log("hi there", name));` to greet every published value, then published values will stop being greeted whenever a garbage collection happens.

    • arnorhs  2 days ago

      This is correct.

      The subscribers are unlikely to be garbage collected with a weak ref as long as something else is pointing to the subscriber, so it would be a viable alternative to manual unsubscriptions - but personally I prefer to give explicit lifecycle controls to the subscriber, if possible.

      1 reply →

chrismorgan  2 days ago

Using the event dispatch mechanism is flat-out bigger, anyway. Here’s the interface of the original script (that is, global pub/sub functions taking a name), except that the receiver site no longer needs to look at the .detail property so it’s better:

  let t={};
  sub=(e,c)=>((e=t[e]??=new Set).add(c),()=>e.delete(c));
  pub=(n,d)=>t[n]?.forEach(f=>f(d))

The original was 149 bytes; this is 97.

(The nullish coalescing assignment operator ??= has been supported across the board for 4½ years. Avoiding it will cost six more bytes.)

  • ftigis  2 days ago

    This isn't the same though. With EventTarget, if one of the callback throws, the later callbacks would still get called. With yours the later callbacks don't get called.

    • chrismorgan  2 days ago

      True, I forgot about that. Habit of working in Rust, perhaps, and generally avoiding exceptions when working in JavaScript.

      Well then, a few alternatives to replace f=>f(d), each with slightly different semantics:

      • async f=>f(d) (+6, 103 bytes).

      • f=>{try{f(d)}catch{}} (+14, 111 bytes).

      • f=>setTimeout(()=>f(d)) (+16 bytes, 113 bytes).

      • f=>queueMicrotask(()=>f(d)) (+20 bytes, 117 bytes).