emit with multiple arguments about mitt HOT 15 CLOSED

Haha, thanks. HOLY SHIT I HAVE WRITTEN WHOLE 200 BYTES !!1!11! 🎉 🤣

from mitt.

and it's functionality not supported by Node's EventEmitter

You're wrong here. Node's emitter support emitting multiple arguments, and that was why i suggested it. We just end up that it is enough to be one argument.

And if you need some kind of "multiple args" you can pass an object which is pretty flexible and powerful enough.

from mitt.

I'm kinda liking the multiple args. BTW after I finally get around to merging your PR I'll just add you as a contributor to the lib. Most of its yours at this point lol

from mitt.

Ahh, I have a very poor memory haha. I wonder if it fits in the 200b budget via your refactor PR (when I get a spare second to merge it 😭)

from mitt.

@rsbondi we already tried everything. Best and in same time fast way is to define few arguments (2-3-4) explicitly. All other EEs which are fast in that same time do such thing - they even save the call to apply.

emit(type, a, b, c) {
  list('*').concat(list(type)).forEach((handler) => { handler(a, b, c); });
}

It not support infinite args, but it kinda feel good and stay at 200b.

from mitt.

@developit actually, my branch currently is exactly 200b without the support for multiple arguments.

It is just a matter of decisions. If we don't support chaining ( #12 ) we could get support for 3 multiple arguments and 199b.

    emit(type, a, b, c) {
      (all[type] || []).map((handler) => { handler(a, b, c); });
      (all['*'] || []).map((handler) => { handler(type, a, b, c); });
    }

from mitt.

Duplicate of #13. The code for this ends up being much too large (...a transpiles to a cloning loop), and it's functionality not supported by Node's EventEmitter, which this library tries to mirror.

from mitt.

It was exactly 200b (in one point of time, in another it was lower, as it is currently 196b) with everything (few other PRs and issues included).

from mitt.

Well then the old fashion way without transpiling should save some bytes

list('*').concat(list(type)).forEach( (f) => { f.apply(null, [].slice.call(arguments, 1)); });

from mitt.

Yup, definitely smaller than the Babel transpiled version. Still bumps things up to around 230 bytes though 🙊. @tunnckoCore if that was 200b including multiple args then that's pretty sweet.

from mitt.

Actually, with 5 multiple arguments support, the CJS bundle is 202b, IIFE is 199b, with 4 multiple args respectively 201b and 197b. With 3 args support - 199b CJS, 196b is IIFE.

Lastest build

		emit(type, a, b, c, d, e) {
			(all[type] || []).map((handler) => { handler(a, b, c, d, e); });
			(all['*'] || []).map((handler) => { handler(type, a, b, c, d, e); });
		}

output

% 1 ❯ nr build                                                                                         February 09, 00:18:17

> [email protected] build /home/charlike/hub/raut/mitt
> npm-run-all clean rollup


> [email protected] clean /home/charlike/hub/raut/mitt
> rimraf dist


> [email protected] rollup /home/charlike/hub/raut/mitt
> rollup -c


> [email protected] postbuild /home/charlike/hub/raut/mitt
> ls -al dist/

total 32
drwxr-xr-x 2 charlike users 4096 Feb  9 00:18 .
drwxr-xr-x 7 charlike users 4096 Feb  9 00:18 ..
-rw-r--r-- 1 charlike users  321 Feb  9 00:18 mitt.iife.js
-rw-r--r-- 1 charlike users  199 Feb  9 00:18 mitt.iife.js.gz
-rw-r--r-- 1 charlike users  312 Feb  9 00:18 mitt.js
-rw-r--r-- 1 charlike users  202 Feb  9 00:18 mitt.js.gz
-rw-r--r-- 1 charlike users  463 Feb  9 00:18 mitt.umd.js
-rw-r--r-- 1 charlike users  267 Feb  9 00:18 mitt.umd.js.gz

using zopfli and uglify plugins, and cleaner npm scripts

from mitt.

@tunnckoCore there's also this change, which could make the size better or worse, not sure. It switches the default module to a crazy global-or-commonjs thing that isn't UMD.

from mitt.

Don't know. I'm using rollup uglify plugin with just opts.compress.warnings: false. Can't get why reserved is needed? We don't need that.

We should look IIFE bundles for the size - they are smallest. We should use plugins for uglify and gzip (using zopfli). And we should stay tuned to ls -al dist - we don't need gzip-size cli and strip json comments.

These 200b is not so real in any way. Users will use at least the UMD bundle, first. Second, sourcemaps are need, so ~30-40b more (for the sourcemap comment). So finally we get ~300b real.

With sourcemaps

drwxr-xr-x 2 charlike users 4096 Feb  9 00:55 .
drwxr-xr-x 7 charlike users 4096 Feb  9 00:55 ..
-rw-r--r-- 1 charlike users  347 Feb  9 00:55 mitt.iife.js
-rw-r--r-- 1 charlike users  227 Feb  9 00:55 mitt.iife.js.gz
-rw-r--r-- 1 charlike users 2239 Feb  9 00:55 mitt.iife.js.map
-rw-r--r-- 1 charlike users  333 Feb  9 00:55 mitt.js
-rw-r--r-- 1 charlike users  224 Feb  9 00:55 mitt.js.gz
-rw-r--r-- 1 charlike users 2233 Feb  9 00:55 mitt.js.map
-rw-r--r-- 1 charlike users  488 Feb  9 00:55 mitt.umd.js
-rw-r--r-- 1 charlike users  294 Feb  9 00:55 mitt.umd.js.gz
-rw-r--r-- 1 charlike users 2238 Feb  9 00:55 mitt.umd.js.map

from mitt.

Hmm - I don't imagine many people are using UMD.. most would either be using CommonJS (the one measured) or ES Modules (smaller, but unrealistic due to ES syntax).

from mitt.

Okey, nevermind. In any way, it is up to you which features to include, but you should choose between "chaining" and "multiple (3-4) args", haha. We can't get both.

from mitt.