-
Notifications
You must be signed in to change notification settings - Fork 438
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: fixes #2, #6, #12 and #13 #19
Conversation
example 'use strict'
var mitt = require('./dist/mitt')
var ee = mitt()
ee
.on('*', (type, arg) => console.log('wildcard:', type, arg))
.on('foo', (one, two, three) => console.log('foo1:', one, two, three))
.on('foo', (one, two, three) => console.log('foo2:', one, two, three))
.on('bar', (arg) => console.log('bar:', arg))
.emit('foo', 1, 2, 3)
.emit('bar', 444)
console.log(ee.all)
var emitter = mitt()
console.log(emitter.all) // => {}
emitter.emit('foo', 777) |
FYI, this PR doesn't follow the indentation style of the original file (tabs). You might want to clean up the formatting to better match the original. |
That's because there's no |
The |
TBH I don't think we can merge anything relying directly on |
src/index.js
Outdated
emit(type, event) { | ||
list('*').concat(list(type)).forEach( f => { f(event); }); | ||
emit(type, arg1, arg2, arg3) { | ||
list(type).forEach((handler) => handler(arg1, arg2, arg3)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dropping the braces in loops here will insert an unused return
statement.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm. Will try it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't know but it adds 2 bytes 😆
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
funky! I never thought to check - I guess that's another one for the "gzip is cool" book haha
@developit 1) this editor config these not have ident size for js files. But as you want.
|
that editorconfig sets tabstops to "tab" here for all files. |
So yea, if we consider 1) dropping toLowerCase(); 2) dropping Set and 3) emitting 2 arguments instead of 3 arguments, then we finish with 201b ;d I switch it and can push if you want. |
Seems like a good update. I'd like more feedback around multiple arguments before we merge that though. Any idea if the way you've attached |
just realized that it is the reason it is 201, not 200 as currently :D need to update the |
I'm fine with either approach for exposing |
Yeah we might want to remove documentation.js output from it I guess. |
Hoooray. We got green. edit: As about the multiple arguments.. It worth nothing. It will lower the size with 3-4 bytes. |
I have never tried multiple arguments with Node's EventEmitter. Not sure if it is supported there. |
Yea it supports. I used them few times. var Emitter = require('events')
var ee = new Emitter()
ee.on('foo', console.log)
ee.emit('foo', 1, 2, 3) |
You can try https://github.com/verbose/verb/tree/dev + verb-generate-readme. It gives a lot more better and meaningful (readme) docs and scaffolding. edit: example: https://github.com/tunnckoCore/koa-better-router |
Looks good! I'm pretty used to Documentation.js though, so unless someone PR's it I'm unlikely to scrap and do something new (also seems like it's a little bit in flux). FWIW I think it'd be fine to use documentation.js' built-in support for publishing an HTML webpage and just have that deployed via gh-pages. That would be a nice place for examples and whatnot. That, or scrap the JSDoc annotations altogether and switch to written documentation, since there are only three methods. Examples and recipes might be more useful than generated docs here. |
So, good night from here, let's get rid of some bytes ;p (as per #13 (comment) and #13 (comment)) |
btw, what you think about the order in emit(type, evt) {
(all[type] || []).map((handler) => { handler(evt); });
(all['*'] || []).map((handler) => { handler(type, evt); });
return ret;
} I believe it should emit wildcards first? and should add test for that |
@developit okey. So it will remain as current :) Let me fix the conflict and we could merge? |
I think there's still the open question of this preventing #1 |
Yea. But I think there are more open issues and wants and PRs for current style/approach (as usual emitter). This PR closes all of them. But okey, we'll wait :) |
Not necessarily wanting to wait on all of it - we could extract the |
I don't see for what conflict you're talking about. If some attribution is needed to the others - I believe I did it correct way, if not sorry. I started that PR with merging them (at least for the tests). Then I just start everything in index.js from scratch to get them fit in 200b. It is alsoo adjusted to the comments from the other issues and PRs.
It's not just that. Initially it was for the #12 (mainly) and #13. But it was not possible to accomplish #12 without some kind of rewriting the whole thing and fit the needs from other PRs + the size limit. |
It's just impossible to merge them one by one, because they separately does not fit in 200b limit (almost). |
Ah my merge conflict comment was just more a general comment. You don't think we could just hold off on the |
Don't know. Do what you want :) I just invest a bit of time and was excited :) I just saying that I don't see any problems in merging it. |
I might merge but then back out the returns. Will be a bit though. Appreciate all your work on this, sorry for being slow heh |
Hoping to merge this today. |
Cool. I'm playing with it few days. For tiny router and tiny store, and actually found https://github.com/tkh44/smitty that gave me some ideas. |
ah nice- you've been playing with the version of mitt from this PR? Good to know it's been used prior to merging. |
@developit yep, with that, which is 196 bytes ;d |
Kk. |
@tunnckoCore looking to merge this - can we just double check what the size hit is for the chaining returns? I'm tempted to defer deciding on return values but the rest of this PR is really in need of being merged. |
Can we merge, and then I can PR for the better rollupconfig and more clean npm scripts using the rollup plugins, so i can be more sure that that is real. Just to proceed and close/clean/fix/resolve most of the opened issues and prs, then we can continue. |
Agreed for sure, just I don't know about the return values. If we merge and release, they are set in stone. Not saying I'm necessarily against chaining, just that it's the only thing in this PR that is causing me to stress :P |
@developit why? what's wrong with the chaining, it is pretty useful. Maybe because you |
My main concerns are that it's not supported in EventEmitter and makes it impossible to support returning an unsubscribe method. I'm not sure about the unsubscribe itself, but it seems a shame to omit that for a sugar syntax in a 200b lib. |
I'm merging, but I'm going to leave |
all
#27 toosmaller
branch?), but we can back with cost of 8 bytes and a small tweak in testsemitter.all
Sorry for the yarn.lock, spaces and semicolons. It seems
eslint --fix
does nothing with thatrecommended
preset.update (17 jan, 18h):
.toLowerCase()
update (18 jan, 03h):