Modules provide a way to encapsulate your application behavior into reusable parts, making it easier to share or organize your code. They are similar to mixins but without their drawbacks. Modules are scoped to a specific state/action slice, preventing implicit dependencies and namespace clashes. This feature promotes code transparency and maintains the benefits of a single state tree architecture.

const foo = {
  state: { value: 1 },
}

app({
  init(state) {
    console.log(state) // => { foo: { value: 1 } }
  },
  modules: { foo },
})

Modules can also have their own modules, creating a nested structure:

const bar = {
  state: { value: 1 },
}

const foo = {
  modules: { bar },
}

app({
  init(state) {
    console.log(state) // => { foo: { bar: { value: 1 } } }
  },
  modules: { foo },
})

Actions inside a module can only call actions within their module or those exposed by modules underneath. This provides a structured approach to managing dependencies, similar to passing props from parent to child components.

Higher-Order Apps (HOAs)

Built-in support for HOAs has been removed in favor of a DIY approach. This change offers greater flexibility and diversifies the ecosystem while simplifying the core of Hyperapp. HOAs are no longer a core feature, allowing us to focus on improving Hyperapp itself.

// Before
app(A)(B)(C)({ ... })

// Now
C(B(A(app)))({ ... })

Container

To specify a different rendering element than document.body, pass the element to the app(props, container) function in the second argument.

app(props, container)

If you were using props.root, you'll need to update your code (#410).

app({
    view,
    state,
    actions,
-   root: document.getElementById("app"),
  },
+  document.getElementById("app")
)

Acknowledgements

We extend our gratitude to everyone who contributed to this second release before 1.0! @Mytrill @Swizz @okwolf @pspeter3 @lukejacksonn @zaceno @johanalkstal @selfup @vdsabev @Kenota