Extend components

[jcubic]

I think this on is features request, it would be nice if you could access state from component like in redux so you don't need to pass state values to custom tags, also access to action would be nice. something like this:

const Editor = (options, state, action) => {

  const oncreate = e => {
    e.appendChild(node)

    setTimeout(() => {
      editor.focus()
      editor.refresh()
    })
  }

  return <div oncreate={oncreate}
              onupdate={onupdate}
              mode={state.mode}
              theme={state.theme}
              lineNumbers={state.lineNumbers} />
}

the change will not break existing apps because options/props will still work the same and state and action will be ignored. In small apps it will doesn't matter but on larger ones when you have 3 levels of nested components/tags you will need to pass state in each component to use it in last component.

[jorgebucaran]

@jcubic Can you please use syntax code fences? It is difficult to read the code. Pick your favorite from ```js or ```jsx . 😏

One more thing, in hyperapp we call the "components" you described custom tags. 🙏:wink:

Now, the signature you are proposing is not possible without either:

1) Changing how h() works, for example, embedding h in app like app.h. 2) Injecting code into these so-called "components" so that when used in your view they return a vnode tree.

Instead of (1) or (2) I recommend you pass the state or a fragment of it to your custom tag when declaring it inside your view.

<MyTag state={state.someNamespace} />

Related

• 238

[zaceno]

@jbucaran

@jcubic said:

so you don't need to pass state values to custom tags

If I understand what this issue is about, it's simply about being spared the hassle of doing what @jbucaran said toward the end of his comment.

So in that sense it seems pretty close to:

https://codepen.io/zaceno/pen/gRvWPx https://gist.github.com/zaceno/83286dfd2a18ebbd3b4f1d7cb5810a0c

[jorgebucaran]

@zaceno I wonder how an implementation of this in core look like? Just curious.

[jorgebucaran]

@zaceno BTW, let's call them something like widgets or state-bound custom tags. If we call it components it will make people think they manage their own state, which is not true.

[zaceno]

@jbucaran: agree! "Widgets" are a good name. Short and unique, and not laden with too many preconceptions from other frameworks. Let's go with that for now.

I'll look into a PR about this anyway. My thinking is like this: My example of "components" (yes, I'll start calling them widgets) works without changes to core -- but currently not in mixins. With some changes to hyperapp's core, it could work in mixins as well.

My concept is just to bind view-functions to the state/actions, BUT once it works in mixins, you could use some external library/user-code to scope the mixin (or rather, the actions and widgets inside it). And that would get you pretty close to what @jcubic is asking and @naugtur s notion of components (but in a cleaner way imo)

I'll make a PR with an example. I'll need a day or two tho