Skip to content
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

Merged
merged 15 commits into from
Feb 25, 2017
Merged

Conversation

tunnckoCore
Copy link
Collaborator

@tunnckoCore tunnckoCore commented Jan 17, 2017

Sorry for the yarn.lock, spaces and semicolons. It seems eslint --fix does nothing with that recommended preset.


update (17 jan, 18h):

  • initially was with toLowerCase, but dropped .toLowerCase()
  • initially was with Set, but dropped and switched to native array

update (18 jan, 03h):

@tunnckoCore
Copy link
Collaborator Author

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)

@dotproto
Copy link
Contributor

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.

@tunnckoCore
Copy link
Collaborator Author

tunnckoCore commented Jan 17, 2017

That's because there's no .editorconfig in the root and it would be fixed when he push it. The only way is to push some editor config and fix it to the original.

@developit
Copy link
Owner

The .editorconfig I'll be adding is here by the way.

@developit
Copy link
Owner

TBH I don't think we can merge anything relying directly on Set. There are other EventEmitter implementations that use that approach, this one is sortof meant to be near-universally compatible (it saddens me to even consider calling it IE9+, I would rather be able to say "it runs in any JS runtime").

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));
Copy link
Owner

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm. Will try it.

Copy link
Collaborator Author

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 😆

Copy link
Owner

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

@tunnckoCore
Copy link
Collaborator Author

tunnckoCore commented Jan 17, 2017

@developit 1) this editor config these not have ident size for js files. But as you want.

  1. Dropping Set it goes ~230+ bytes somehow. I can try again later ;d

@developit
Copy link
Owner

that editorconfig sets tabstops to "tab" here for all files.

@tunnckoCore
Copy link
Collaborator Author

tunnckoCore commented Jan 17, 2017

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.

@developit
Copy link
Owner

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 all is smaller or larger than the old argument approach? (sorry for all the questions haha)

@tunnckoCore
Copy link
Collaborator Author

Any idea if the way you've attached all is smaller or larger than the old argument approach?

just realized that it is the reason it is 201, not 200 as currently :D need to update the ignore case tests

@developit
Copy link
Owner

I'm fine with either approach for exposing all - it's a little sad that we have to do so, but the tests rely on it. Maybe it'll be something we compile out?

@developit
Copy link
Owner

Yeah we might want to remove documentation.js output from it I guess.

@tunnckoCore
Copy link
Collaborator Author

tunnckoCore commented Jan 17, 2017

Hoooray. We got green.

edit: As about the multiple arguments.. It worth nothing. It will lower the size with 3-4 bytes.

@developit
Copy link
Owner

I have never tried multiple arguments with Node's EventEmitter. Not sure if it is supported there.

@tunnckoCore
Copy link
Collaborator Author

tunnckoCore commented Jan 17, 2017

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)

@tunnckoCore
Copy link
Collaborator Author

tunnckoCore commented Jan 17, 2017

Yeah we might want to remove documentation.js output from it I guess.

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

@developit
Copy link
Owner

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.

@tunnckoCore
Copy link
Collaborator Author

tunnckoCore commented Jan 18, 2017

So, good night from here, let's get rid of some bytes ;p (as per #13 (comment) and #13 (comment))

@tunnckoCore
Copy link
Collaborator Author

tunnckoCore commented Jan 18, 2017

btw, what you think about the order in .emit?

		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

@dotproto dotproto mentioned this pull request Jan 18, 2017
@dotproto dotproto mentioned this pull request Jan 20, 2017
@tunnckoCore
Copy link
Collaborator Author

@developit okey. So it will remain as current :)

Let me fix the conflict and we could merge?

@developit
Copy link
Owner

I think there's still the open question of this preventing #1

@tunnckoCore
Copy link
Collaborator Author

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 :)

@developit
Copy link
Owner

Not necessarily wanting to wait on all of it - we could extract the return this'es and move forward with the rest. That's one painful part of the lib being so small - everything is a merge conflict lol

@tunnckoCore
Copy link
Collaborator Author

tunnckoCore commented Jan 22, 2017

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.

we could extract the return this'es

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.

@tunnckoCore
Copy link
Collaborator Author

It's just impossible to merge them one by one, because they separately does not fit in 200b limit (almost).

@developit
Copy link
Owner

Ah my merge conflict comment was just more a general comment. You don't think we could just hold off on the return this'es in this PR?

@tunnckoCore
Copy link
Collaborator Author

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.

@developit
Copy link
Owner

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

@tunnckoCore tunnckoCore mentioned this pull request Jan 27, 2017
@developit
Copy link
Owner

Hoping to merge this today.

@tunnckoCore
Copy link
Collaborator Author

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.

@developit
Copy link
Owner

ah nice- you've been playing with the version of mitt from this PR? Good to know it's been used prior to merging.

@tunnckoCore
Copy link
Collaborator Author

@developit yep, with that, which is 196 bytes ;d

@developit
Copy link
Owner

Kk.

@developit
Copy link
Owner

@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.

@tunnckoCore
Copy link
Collaborator Author

What I see is 13 passing tests, chaining ( #12 ), Object.create(null) ( #11 , #9 ) and 196b 🎉

I kinda still can't believe it :D

@tunnckoCore
Copy link
Collaborator Author

tunnckoCore commented Feb 23, 2017

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.

@developit
Copy link
Owner

developit commented Feb 24, 2017

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

@tunnckoCore
Copy link
Collaborator Author

@developit why? what's wrong with the chaining, it is pretty useful. Maybe because you .emit from component on-* events haha? You kinda can detect if is-mitt :D like o && o.all && o.emit && o.on?

@developit
Copy link
Owner

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.

@developit
Copy link
Owner

I'm merging, but I'm going to leave all as an argument instead of property and remove the return values (at least temporarily) so this doesn't have to be a major version bump.

@developit developit merged commit 29c4aa1 into developit:master Feb 25, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants