Introduce init and modules.

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

[zaceno]

My previous comment was mostly against the idea of using actions inside init to set up initial state if that’s what you need (because it introduces two different types of actions). Of course init will need access to the final actions object (otherwise how to set up mousemove event handlers and similar).

So it was nothing against this proposal. I am for this proposal 😃

I’m especially a fan because it takes hyperapp one step further along the lines of hyperapp-partial. When this proposal makes it in I can decommission partial and just make two separate HOA (one to add an event bus, and one for prewired components in modules)

[zaceno]

@augnustin I’d go with what @SkaterDad said, because it keeps state management logic out of the view.

In case you’re interested about modules and initialization with current versions of hyperapp, I’ve written a bit about it. Nothing official - just my approach, but in case you’re interested:

https://zaceno.github.io/hypercraft/post/modular-apps/ https://zaceno.github.io/hypercraft/post/initialization/ https://zaceno.github.io/hypercraft/post/cross-namespace-action-calling/