Components

Let’s discuss how components could look like in a future version of HyperApp.

Submitted Proposals

• https://gist.github.com/zaceno/83286dfd2a18ebbd3b4f1d7cb5810a0c via @zaceno
• https://gist.github.com/Swizz/8437df6ac5ec4985e72e648d242f6a9f via @Swizz

---

Example

counter.js

const Counter = (props, children) => ({
  state: {
    value: props.value
  },
  view: ({ value }, { inc, dec }) =>
    <div>
      <h1>{state.value}</h1>
      <button onclick={inc}>+</button>
      <button onclick={dec}>-</button>
    </div>,
  actions: {
    inc: state => state + 1,
    dec: state => state - 1
  }
})

index.js

app({
  state: {
    title: "Hello."
  },
  view: (state, actions) =>
    <main>
      <h1>{state.title}</h1>
      <Counter value={1} />
    </main>
})

Credits

All credit goes to @MatejMazur:

• https://github.com/MatejMazur/hyperapp
• https://github.com/MatejMazur/hyperapp-component-experiment

Related

• #147
• #219

[jorgebucaran]

I am having mixed feelings about components and I am not even sure we should add a new core concept to the framework. I am not even sure we even have a problem. I say, let’s build one or two cool apps first and then revisit this issue. 🤔😅😎

Now, I’m still interested to see @naugtur’s #245’s final form and the door is open to anyone who wants to add more to this discussion.

I am glad this conversation happened, though, because it motivated me to revisit hyperapp core values and I can confidently say I like it now more than ever.

To summarize my feelings about components:

@zaceno’s But the patterns I’ve seen so far have state and actions that are defined very independently. Even though we’re merging their state and actions to the main tree, they don’t seem to have any access to the main state tree. So how are the components meant to communicate? If the answer is: “via the props”, then they are effectually no different to locally stateful components. And if that’s the case, then what’s the point of the “one-state-to-rule-them-all”?

But nothing is lost. On the contrary, we’ve gained the insight that there exist patterns that can help you create complex applications without losing the benefits of a single state tree.

Patterns

Widgets

@zaceno’s state/action bound custom tags is interesting and could be published as an independent module. I like to think of them as “widgets”. 🤓

See: https://codepen.io/zaceno/pen/gRvWPx

Split-mixins

@MatejMazur’s Split-mixins is a clever trick that requires no changes to core and lets you use mixins to achieve something similar to stateful components.

const MyComponent = ({ state, view, actions }) => view
   ? ({ state, actions, events, mixins }) // good ol' mixin
    : <main>...</main> // a custom tag

Mixins

@Swizz Super-powered mixins.

See: https://github.com/hyperapp/hyperapp/issues/238#issuecomment-310999839.

Other

• @jamen’s components. https://git.io/vQ0cq

Final remarks

We’re all (I am!) on a learning curve and tyring to figure this out. I am sure more patterns will show up, so please share your research and findings.

Thank you all, for your feedback and such an epic thread! 💥 🎉🥇

[jorgebucaran]

@MatejMazur @Swizz @jamen @everyone

How does everyone feel about this approach?

app.js

import { h, app } from "hyperapp"
import MyCounter from "./counter"

app({
  state: {
    title: "Hello."
  },
  view: state =>
    <main>
      <h1>{state.title}</h1>
      <MyCounter initialValue={1} />
    </main>
})

counter.js

import { h, component } from "hyperapp"

export default component(({ initialValue }) => ({
  state: initialValue,
  view: (state, { up, down }) =>
    <div>
      <h1>{state}</h1>
      <button onclick={up}>+</button>
      <button onclick={down}>-</button>
    </div>,
  actions: {
    up: state => state + 1,
    down: state => state - 1
  }
}))