raiondesu / eventhoven Goto Github PK

• Contributions
• Installation
• Simple usage example
• eventMap
• emit
  • Awaiting promised emits
• subscribe (on)
• subscribeToAll (onAll)
• unsubscribe (off)
• unsubscribeFromAll (offAll)
• wait
• debug
• Collections
  • eventCollection
  • emitCollection
  • subscribeCollection
  • unsubscribeCollection
• Meta-events
  • metaEvents
  • emitMeta

It is desirable to have bundles for every situation.

Right now, this lib lacks:

• Single-file UMD (ES5)
• Single-file IIFE (ES5, polyfills)
• Node CommonJS (ES6+)

Currently this yields cannot read property "set" of undefined.

Current debugging system allows to set a custom debugging function, but there's no way to disable debugging with that custom function if a reference to it is lost (this could happen when dealing with switching isolated contexts like iframes or remote debugging ports).

It also requires passing an object 100% of the time, which is exhausting in itself.

Is there a way to make this work easier?

Currently, handler's return values are void-ed, making no use of a possible feature.

Maybe allow event handlers to return a value, even if not a typed one?

This could be used for many things.

Is your feature request related to a problem? Please describe.
It's understandable if a library is tuned to a specific programming style or paradigm, but it's never a good sign if a library restricts the end user in ways of achieving their goals.

A class API would solve the problem of a low compatibility of this library with the OOP-style.

Describe the solution you'd like
A class that utilizes event collections in order to encapsulate and combine the API.

https://github.com/raiondesu-experiments/eventhoven/blob/bbb96603a1e46fd08514ffe250c931035bda45d3/src/emit.ts#L36

This event context should be introduced in some other way.
Need to remove this for now

Is your feature request related to a problem? Please describe.
Current README is getting very long and tedious to read. This might scare off some users that just want a simple event manager.

Describe the solution you'd like
A powerful solution to this would be a custom website for documentation with a possibility to code interactive tutorials (vuepress-based, maybe)?

Describe alternatives you've considered
Another solution would be to transfer docs to github wiki, but this provides no interactivity. And the structurization abilities are quire poor.

Currently, the debug output is very basic, showing only the essential info.

Here's how it could be improved:

• Show milliseconds too - this can be crucial in determining the true order of operations
• Colorize the event name and some other info - could help distinguishing between different log entries

Maybe do this only for emits?

This is a shame for node<v12 users...

This is a direct consequence of using array.splice() with array.findIndex:

https://github.com/raiondesu-experiments/eventhoven/blob/0eb59788074d1586bcdfa013f946a398a8494c3c/src/unsubscribe.ts#L30

Is your feature request related to a problem? Please describe.
While #42 introduced a solid way to handle events in an OOP-style, it's still not a 1-to-1 mapping of all Eventhoven functionality.
Currently, these things are missing from the implementation:

• Ability to add or remove events from the map, as it is possible via the eventMap function;
• Ability to properly implement inheritance patterns in order to modify current behaviour of events.

Currently, all eventhoven functions are contextless (have no this bound to them).
And this simplifies a lot of things.

However, handlers contain user's code. And a user may need to provide a separate context for them. So why not add it as a feature?

There's a definite need to test typescript typings. It would be possible using something like dtslint.

Would allow to wait for event being emitted by returning a promise. Useful feature.

Describe the bug

It might be considered unexpected behavior when an event awaits all async meta-event-handlers before executing actual event handlers for the event.

To Reproduce
Steps to reproduce the behavior:

1. Create an async function that resolves after {N} seconds
2. Add it as an async handler to EMIT meta-event
3. Emit any event
4. See execution flow being blocked for {N} seconds due to awaiting the execution of the meta-event handler

Expected behavior
Expected execution flow to not be blocked by the meta-event.

Environment (please complete the following information):

• OS: Windows
• Platform:
  • Browser (all)
  • Node (all)
• eventhoven version: v0.11.0-rc.1

Is your feature request related to a problem? Please describe.
Current way of result handling in emitters and handlers is half-baked - handlers can return data to emitters, but they do not have any knowledge or control on how this data is processed or handled.

Describe the solution you'd like
Provide a new property to the event context - a typed results array that contains all the results of all previous handler's execution.

Example

on(someMap)('someEvent')(ctx => {
	const isMyHandlerFirst = ctx.results.length === 0;
})

Currently, if you apply once to a very expensive (computationally) handler, and then trigger the event it was subbed to from an async environment twice or more - the handler will still be executed more than once.

This happens because the once function calls unsubscribe after the handler finishes executing. Ideally, once should unsub the handler right at the start of the execution to ensure the actuality of the event-map's state.

Currently, the debug function is the only one that doesn't embrace the curried single-argument policy of the rest of this lib.

It's a well-known use-case to await the execution of all events, while also allowing handlers to not block the execution flow.

This is needed. Soon.

Describe the bug
The type of the event context (TEventContext) is not inferred correctly in event handlers passed to subscribe function.

To Reproduce

import { eventMap, on } from 'eventhoven';

const map = eventMap({
  event(_): 42 { return 42; }
});

on(map)('event')(ctx => {
  ctx.event; // string | number | symbol
  ctx.unsubscribe // TUnsubscribe
});

Expected behavior

import { eventMap, on } from 'eventhoven';

const map = eventMap({
  event(_): 42 { return 42; }
});

on(map)('event')(ctx => {
  ctx.event; // 'event'
  ctx.unsubscribe // TUnsubscribe<'event'>
});

Environment (please complete the following information):

• OS: Windows
• Platform:
  • Browser - any
  • Node 12+
• eventhoven version: v1.0.0

Jest is set up.

Only need to write them.

Since the subscribe function returns the unsubscribe for the specific handler - why even pass the once arg?
One could just immediately call the unsubscribe inside of the handler!

Instead of just the current one.

Browser modules require special treatment in a form of a .js extension appended to all module references.
This is, of course, solvable via a server settings (automated redirect from no extension to .js extension), but this is a too complicated workaround for some situations.

Node works fine with .js extensions too, btw.

Even though types are present:

The arguments' types in the passed handler are set to any. 😕

This doesn't really break things though.