Proposal for version 3.0

scottcorgan commented 7 years ago

After thinking about the implementation details and the API surface area I'd like to make the following proposal for changing this package and making another package based of this package:

`tiny-emitter`

This would be rewritten in the es2015 class syntax with the following API:

class Emitter {
  on() {}
  off() {}
  emit() {}
}

This removes the once() function in favor of a smaller file API surface area. once() can be emulated easily enough. Also, this makes the package way smaller as most people code bases have a transpilation step anyway. We could also provide a transpiled and minified file in the dist directory.

`tiny-emitter-extended`

Then, we would create a new package that extends tiny-emitter called tiny-emitter-extended with the follow API:

class EmitterExtended extends Emitter {
  once() {}
  onAll() {}
  offAll() {}
  onceAll() {}
  emitAsync() {}
}

This is a convenience package that adds a little bit more wait.

Notable:

once() moved here for convenience
onAll() or on('*') would add a wildcard listener for every event
offAll() or `off('*') would unsubscribe from every event
onceAll() or once('*') would subscribe to all events once
emitAsync() would emit the event on next animation frame for convenience of when you define your listeners

How to respond

Please respond with ideas, changes, recommendations, and dislikes (hopefully with solutions) so that I know if we should move forward with these changes, or not 👍

MLoughry commented 7 years ago

I'm all in favor of the changes. Currently, tiny-emitter's non-ES6-compliant export syntax (along with the larger issue of webpack needing to update their uglifyjs-webpack-plugin) are roadblocks to our Typescript project's enabling of webpack's tree-shaking and scope-hoisting optimizations.

scottcorgan commented 7 years ago

@MLoughry thanks for the feedback! Is the module syntax the only blocker for you?

MLoughry commented 7 years ago

For us, yes.

lmk123 commented 6 years ago

The CommonJS module syntax also the blocker for me.

When I use it in a TypeScript project, I have to import it like this:

import TinyEmitter = require('tiny-emitter')

It's ok if I set module: 'commonjs' in my tsconfig.json, but if I written an library and want to bundle my modules into one file using rollup-plugin-typescript2, the module option must be es6 since Rollup only accpet ES6 modules, so:

Rollup only accpet import TinyEmitter from 'tiny-emitter' syntax but in TypeScript I must use import * as TinyEmitter from 'tiny-emitter'. I can set allowSyntheticDefaultImports to true in my tsconfig.json to workaround it, but the users of my library also need to set this too, or TypeScript will show an error in console.
TypeScript doesn't allow import an CommonJS module that export an Class using ES6 module syntax . See https://stackoverflow.com/a/39415662/4002714

Dan503 commented 6 years ago

Instead of getting people to run an extra npm install and managing a completely separate repo, you might want to try using the method I used on mq-js.

I had a bunch of extra functionality that I wanted to provide but I didn't want to bloat out the core plugin with stuff most people were never going to touch.

So what I did was I created a "plugins" folder that contains one file for each extra plugin. I also created a shared js file for things that needed to be shared across multiple JS files.

Benefits of this method:

One repo controls everything (bad for massive things like Babel but good for small things like this)
People only need to import what they need to help keep file size down
All the plugins are downloaded along with the main package so people don't need to run extra npm install commands
Without the npm install commands it causes less friction for people to use the plugin so people are more likely to use the plugin features
one more benefit to no npm install command, people are free to add a plugin that previously wasn't in use without forcing all their team members to update their node_modules folder with an npm install command

mraucorp commented 5 years ago

once is very useful 'do this job on next emit' is good to have on library, instead of making unnecessary named handler and not to forgot extra fire of .off method inside

danguilherme commented 5 years ago

Just to keep the discussion alive in 2019, CommonJS module syntax is also a blocker for me.

scottcorgan commented 3 years ago

I know it's been awhile, but I'd be happy to merge a PR for this to be rewritten in ESM.

hit12369 commented 3 years ago

I've made a very small (< 0.3 k) ES module compatible event emitter using native EventTarget. https://github.com/hkk12369/pico-emitter

scottcorgan / tiny-emitter