Revamp events/emit API.

#259 has been merged, #275 is also on the way and we’ve decoupled the event emitter from app().

Thanks @zaceno and everyone else: @lukejacksonn @selfup @jamen @dodekeract who contributed to the discussion.

As a result, you can now create isolated hyperapps that can communicate to each other or use the emitter to communicate with your hyperapp from other parts of your application.

I think the API now looks wonkier, however, but I just had an idea about how we could utilize #259 to revamp the events API and events function signature.

Code is worth a thousand comments so here is what I am talking about:

const { emit } = app({ state, view, actions, mixins })
  .on("ready", (state, actions, data /*,emit*/) => {
    /*
      We don't need emit as a last argument here anymore.
    */
  })
  .on("render", (state, actions, data) => {})
  .on("action", (state, actions, data) => {})
  .on("update", (state, actions, data) => {})

As for mixins, we can simply pass the emitter to them.

const MyMixin = (app, { emit, on }) => ({
  ...
})

Changes

• This means we don’t need app.events anymore.
• I’ve also renamed loaded to ready. This makes sense now that app() is to become sync #275.

[jamen]

I’m not really a fan of adding .on(...). It seems like an odd addition to me, when everything else is specified through the object. I like how centered that is personally.

Also, inside mixins are you supposed to set emit.on(...) at the base?

const MyMixin = (app, emit) => {
  emit.on('ready', (state, actions) => {
    // ...
  })

  return {
    actions,
    state,
    // ...
  }
}

This doesn’t really appeal to me.

[jorgebucaran]

Thanks @ngryman!

I received a lot of great feedback here.

Closing in favor of https://github.com/hyperapp/hyperapp/issues/278.