[RFC] What if hyperapp was just a bit less magical and a bit more transparent?

This is not a proposal to rewrite hyperapp, but just an attempt to gather some feedback from the community about our API.

If this were to happen it would be a major breaking change. This would be so major that one might as well publish it as a different “framework”. 😉

I’d just like to share the API I thought up with all of you so help me decide if this could ever be for us or if I should explore this idea elsewhere. 🤔

Here it comes…

import { h, app } from "hyperapp"
const { render, call } = app({ count: 1 })

document.body.appendChild(
  render(state => (
    <main>
      <h1>{state.count}</h1>
      <button onclick={() => call(state => ({ count: state.count + 1 }))}>
        +
      </button>
      <button
        onclick={() =>
          setTimeout(() => {
            call(state => ({ count: state.count - 1 }))
          }, 1000)}
      >
        -
      </button>
    </main>
  ))
)

Please give it 5 minutes and think about all the implications. See how by decoupling render and update from the app call that means we no longer need actions or events. And mixins, well those can be implemented in a manner similar to Redux enhancers, as the second argument to the app() call.

On the other hand you are responsible for initializing the app yourself and merging the state, actions and other stuff exported by mixins or component-like mixins.

I am not in favor or replacing the current API for this (yet), but I am starting to like it a lot. Like @lukejacksonn said, food for thought. 🍝

EDIT: Corrected as pointed out by @okwolf.

[zaceno]

I think it would be worth exploring, and I’d like to experiment with it. Perhaps we could create a branch for it? Publish it as hyperapp2000 or something.

It’s hard to say yay or nay off hand without exploring it a bit in code. I’m thinking about some of the patterns I depend on (wether kosher or not), such as custom-events for separating concerns, scoped updates, and prewired components. They’ll probably look a lot different if they’re even relevant under this new paradigm.

One thing I like about the current paradigm, is that the mixins and events system gives you one central place to customize a lot of things. If we don’t have a render event in the new paradigm, for instance you can’t inject other stuff to the view as arguments (if that’s what you want). Not via a mixin anyway. You’d have to wrap the render function.

[danigb]

Wow. Conceptually it looks awesome to me. I don’t know exactly what would be the practical implications and if the developer experience would be better or not. But this seems to summarize the essence of the functional UI paradigm, and the flexibility it exhibits is amazing.

Please release it in any way so we can play with it.

And by the way, I’m following you “behind the trenches” and I’m impressed by the community work you all are doing: making all the evolution of the library transparent, and involving all the people. Congrats 👏 👏