Comment by arnorhs

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()

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.

Reply View 4 replies

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.

Reply View | 2 replies
- 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.
  
  Reply View | 1 reply
  
  AgentME 2 days ago
  
  If the listener is a fresh function passed straight to the listen method as in my example, nothing else will have a reference to it besides the event target, and if that's a weak reference then it will get collected eventually and effectively unsubscribed on its own. Weak references don't make sense at all to use for general event listeners like this.
  
  Reply View | 0 replies
[removed] 3 days ago

[deleted]

Reply View | 0 replies

[removed] 3 days ago

[deleted]

Reply View 0 replies

chrismorgan 3 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.)

Reply View 2 replies

ftigis 3 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.

Reply View | 1 reply
- chrismorgan 3 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).
  
  Reply View | 0 replies

nsonha 3 days ago

if one listener throws it will break the entire channel

Reply View 0 replies