We don't have an elegant way to call any actions, subscribe to global events or kickstart ourselves when our app loads. We can call actions after we return from app() but packages like the router, a mouse / keyboard interop interface, etc., could be exposed as modules and for their initialization needs, we can introduce a new init function. 🎉

By the way, modules are not like mixins as they would be scoped to a state & action slice, that you can't opt out from.

import { whopper } from "./whooper"
import { mouse } from "./mouse"

import state from "./myState"
import actions from "./myActions"
import view from "./myView"

app({
  init(state, actions) {
    // Subscribe to global events, start timers, fetch resources & more!
  },
  state,
  actions,
  view,
  modules: { whopper, mouse }
})

The modules whopper and mouse of this example can definitely expose their own init function. They would be called after the top-level init with a slice of the state and actions, e.g., state["whopper"] and actions["whopper"], just how it works with actions.

In @zaceno's words, what's the difference between modules and mixins and how do we explain their overlap with HOAs?

This actually gets at the core of the problem I saw with mixins (and why I wanted them renamed from plugins as they once were called): they basically served two purposes: either to A) augment hyperapp’s features, or B) to modularize your app. Now, modules is only for (B), and we have HOA for (A).

/cc @lukejacksonn @zaceno @andyrj @Swizz