PiletApi's `once` throws when `this` context is `undefined`

[manuelroemer]

Bug Report

For more information, see the CONTRIBUTING guide.

Prerequisites

• [x] Can you reproduce the problem in a MWE?
• [x] Are you running the latest version?
• [x] Did you perform a search in the issues?

Environment Details and Version

Piral 1.4.3 on all up-to-date browsers.

Description

I have code similarly to the following in a Piral app shell React component:

const { once, off } = usePiletApi();
// ...

useEffect(() => {
  const handler = () => /* ... */;
  once('my-event', handler);
  return () => off('my-event', handler);
}, [once, off]);

This code throws the following error (taken from Firefox):

The line originates here:

Steps to Reproduce

The issue can easily be reproduced by adding this test case to api.test.ts:

it('can call destructured "once" function without error', () => {
  const events = createListener(undefined);
  const api = initializeApi(moduleMetadata, events);

  // This works ✅
  api.once('my-event', () => {});

  // This fails ❌
  const { once } = api;
  once('my-event', () => {});
});

Expected behavior

once can be called in contexts where this is undefined.

Actual behavior

once throws, as described above.

Possible Origin/Solution

One solution for this would be the following change in api.ts:

export function initializeApi(target: PiletMetadata, events: EventEmitter): PiletApi {
  return {
    on: events.on,
-   once: events.once,
+   once: events.once.bind(events),
    off: events.off,
    emit: events.emit,
    meta: Object.assign({}, target),
  };
}

Not sure if this is the best one or if this can have any side effects? If yes, we could/should prob. do this for all events, not just once. I can make a PR if this is fine.

[FlorianRappl]

Well bind works or alternatively, you could also make it another lambda ((...args) => events.once(...args)). I think going for the bind is great - let's do that!

Alternatively, let's check the implementation and maybe once can be done in a way that does not require this (and let's check that the others don't suffer from this problem; I think they don't).

[manuelroemer]

Alternatively, let's check the implementation and maybe once can be done in a way that does not require this (and let's check that the others don't suffer from this problem; I think they don't).

The others don't seem to have the same problem. I think the only issue that might arise for them in this scenario is that method chaining might be broken. They return this, for example in on:

on(type, callback) {
  // ...
  return this;
}

So, if you were to do on('foo', handler).once('bar', handler) or something similar, you might run into issues.

I think going for the bind is great - let's do that!

Great, sounds like a plan! I'll tackle it.

[FlorianRappl]

Yeah with the chaining in mind I'd actually improve the basis for this.

We should have the events properly captured.

[FlorianRappl]

Instead of

return {
  on() {
    // ...
    return this;
  },
  // ...
}

we'd go for

const events = {
  on() {
    // ...
    return events;
  },
  // ...
};
return events;

The main problem / issue that I see is that right now the chaining on an "api" works also with the full API - while with this approach it only works on a subset (events).

[manuelroemer]

The main problem / issue that I see is that right now the chaining on an "api" works also with the full API

Ah, I see. I do think though that this is not really "known"/used because TS, at the very least, says that the result is an EventEmitter, not the full API. But fair point.

[FlorianRappl]

Ah, I see. I do think though that this is not really "known"/used because TS,

Yes - otherwise it would have been a breaking change.