Skip to content

Star handlers called without the event type as the first arg #2

Description

@oaleynik

Looks like all star handlers should be called with type as first argument, aren't they?

image

Activity

  1. changed the title [-]Star handlers should be called with event type as the first arg[/-] [+]Star handlers called without the event type as the first arg[/+] on Jan 15, 2017
  2. developit commented on Jan 15, 2017

    @developit
    Owner

    heh! I only realized after publishing that I'd made the wrong call there but then tweeted the right one. Thanks for the PR.

  3. tunnckoCore commented on Jan 16, 2017

    @tunnckoCore
    Collaborator

    just sorry for the offtopic... @oaleynik which is that theme that you are using? I'm new to Atom and trying to find some meaningful theme for syntax.

  4. developit commented on Jan 16, 2017

    @developit
    Owner

    @tunnckoCore that's actually my editor - I commented with the setup in this issue (apparently people really like my editor setup haha).

  5. tunnckoCore commented on Jan 16, 2017

    @tunnckoCore
    Collaborator

    Haha, great & thanks. I'll try the syntax theme. Few weeks on Atom and can't find meaningful theme, tried dozen but all are absolutely awful.

  6. oaleynik commented on Jan 17, 2017

    @oaleynik
    Author

    @tunnckoCore yeah, that screenshot is the ctrl+c/ctrl+v from Twitter :)
    Currently I use https://github.com/apex/apex-ui and https://github.com/apex/apex-syntax created by legendary @tj - I found it super "disruption free" because of absence of the color "noise."

    Some other themes I like include:

    • Chester
    • Github Atom Light
    • Material
    • Gloom
    • One Dark Vivid

    It of course depends on the mood, time of the day when I work, moon phase, etc.. :)

    @developit very sorry for the offtopic :)

  7. developit commented on Jan 17, 2017

    @developit
    Owner

    One Dark Vivid for life (though now I'm looking at Gloom)

  8. tunnckoCore commented on Jan 17, 2017

    @tunnckoCore
    Collaborator

    @oaleynik holy shit, so clean and enough, I'll try it, because screenshot is not enough for me :) Thanks again.

    So TJ is still so amazing person, haha.

    very sorry for the offtopic :)

    meh.. it happens some times 😆

  9. tunnckoCore commented on Jan 17, 2017

    @tunnckoCore
    Collaborator

    Btw, a bit on topic.

    What about that (fixes #2 - this, resolves #12, 197b and in bonus: you can access the all)

    let ret = {
      all: {},
      on (type, handler) {
        list(type).push(handler)
        return ret
      },
      off (type, handler) {
        let e = list(type)
        e.splice(e.indexOf(handler) >>> 0, 1)
        return ret
      },
      emit (type, event) {
        list(type).map((f) => f(event))
        list('*').map((f) => f(type, event))
        return ret
      }
    }
    
    let list = (type) => ret.all[type = type.toLowerCase()] || (ret.all[type] = [])
    
    module.exports = () => ret
  10. tunnckoCore commented on Jan 17, 2017

    @tunnckoCore
    Collaborator

    Damn, I'm god? 🚀 179b with #8

    let mitt = {
      all: {},
      on (type, handler) {
        list(type).add(handler)
        return mitt
      },
      off (type, handler) {
        list(type).delete(handler)
        return mitt
      },
      emit (type, event) {
        list(type).forEach( f => f(event))
        list('*').forEach( f => f(type, event))
        return mitt
      }
    }
    
    let list = (type) => mitt.all[type = type.toLowerCase()] || (mitt.all[type] = new Set())
    
    export default () => mitt

    usage

    var mitt = require('./dist/mitt')
    var ee = mitt()
    
    ee
      .on('*', (type, arg) => console.log('wildcard:', type, arg))
      .on('foo', (arg) => console.log('foo1:', arg))
      .on('foo', (arg) => console.log('foo2:', arg))
      .on('bar', (arg) => console.log('bar:', arg))
      .emit('foo', 123)
      .emit('bar', 444)

    edit: so we freely can implement multiple args - we have huge room :D

  11. tunnckoCore commented on Jan 17, 2017

    @tunnckoCore
    Collaborator

    So in short. Can I PR with fixing #2, #3, #12, #13 and bonus accessing all with final 200b exactly? Then you can update the build process and package.json things.

  12. developit commented on Jan 17, 2017

    @developit
    Owner

    @tunnckoCore your implementation returns the same instance for every mitt() call, which means listeners are shared for all instances. It needs to return a new instance for each mitt() call so it's not just a singleton.

  13. tunnckoCore commented on Jan 17, 2017

    @tunnckoCore
    Collaborator

    Hm. Actually, yea. I get some tests.

  14. added a commit that references this issue on Jan 17, 2017
    a6190e9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions