Need to dynamic actions in order to support code splitting

#435 showed its possible to write an HoA to encapsulate state+action+view into module and https://github.com/hyperapp/hyperapp/issues/435#issuecomment-340067619 showed its possible to load lazy said module, except for the module actions.

Motivation

Code splitting.

Problem

There is currently no way to add actions dynamically.

Possible Solutions

1. Include addAction action in app

• solves the problem in the most direct way

2. Include loadModule action in app

• solves the bigger issue at the same time

3. Merge the concepts of state and actions

• state is expected to change, so what if we just put state and actions in the same place?
• replace state and actions with root, keep view
• allow root to hold both data and functions. functions would take in root and slice the tree as it does now
• functions return and object which will merge into the subtree of where it lives, it can return both data and more functions (aka actions!)
• since actions don’t need to be there at init time, then modules don’t need to exist either! modules can be put directly on the root or added during init or add lazily later

Option 3 is most interesting to me since it removes even more concepts from Hyperapp.

[jorgebucaran]

@Pyrolistical I have a contrived example with dynamic actions for the models branch with a few updates.

Here is the code:

const model = {
  count: 0,
  new: () => store => ({
    count: store.count - 1,
    mult: () => store => {
      return {
        count: store.count * 10
      }
    }
  }),
  up: () => store => ({ count: store.count + 1 })
}

const view = store => (
  <main>
    <h1>{store.count}</h1>
    <button onclick={store.up}>Increment</button>
    <button onclick={store.mult}>Multiply ({store.mult ? "Ready" : "Not Ready"})</button>
    <button onclick={store.new}>Add Dynamic Action</button>
  </main>
)

app(model, view)

[zaceno]

Hmm. I may not be fully grasping the use case here, but if we’re talking about code-splitting (so the async loading of modules/parts), then each dynamically loaded module would have to be quite independent (since it can’t know for sure if any of the other modules are loaded or not).

My approach in such a scenario would probably be to have each module as it’s own app({..}). One master app to manage the fetch/load/initializing of sub apps.