Remix clone Hacker News

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 | parent | next [-]

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 | parent | next [-]

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 | parent [-]

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.

	▲	AgentME 2 days ago \| parent [-]
		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.

▲

3 days ago | parent | prev [-]

[deleted]

▲ 3 days ago | parent | prev | next [-]

[deleted]

▲ chrismorgan 3 days ago | parent | prev | next [-]

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 | parent [-]

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 \| parent [-]
		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).

▲ nsonha 2 days ago | parent | prev [-]

if one listener throws it will break the entire channel