Hyperapp: Containers? Yay/nay?

[Pyrolistical]

I hacked up a container mixin: https://github.com/Pyrolistical/hyperapp-container

Usage: https://github.com/Pyrolistical/hyperapp-container/blob/master/example/application.jsx

I took the classic counter example and created a new <Counter /> component and then created 2 instances of it. Each counter holds its own state. I even demo both how parents can push data down to containers using props and how children can send data back up.

The main goal of this project is being able to pull counter into its own file.

You can see the final result in this screen cap:

The dirty mixin hack: https://github.com/Pyrolistical/hyperapp-container/blob/master/index.js

All the mixin does is store the state and actions onto the application. I used a dirty hack and require an id for all containers so I know how many instances of state to create.

What does everything think? Do we like the idea of breaking down the application state into a tree of stateful containers and stateless components as leaf nodes?

[Swizz]

As your goal seem pretty aligned, is this possible to have a pretty comparison with MatejMazur/hyperapp-fragment ?

hyperapp-fragment choose to use an HoF too, but produce a mixin, in a purtiy way. Mixins that be scoped to a fragment of the common state tree.

I may be wrong, hyperapp-container use the same function as HoF and mixin, and use only the view to do the state related stuffs.

[jorgebucaran]

@MatejMazur @naugtur Ping.

[MatejBransky]

It looks interesting. I think that it's worth exploring. But as @Swizz mentioned it does everything in the view part of the app as our previous tries. Is it ok? Because it breaks single source of truth (hmm..it looks like stateful components). You could avoid that by initializing in mixins (for example mixins: [Counter(2)] and then you can call only(!) twice this component in the app.view <Counter id={1} .. />...<Counter id={2} ... /> but then it looks weird too and it's more error-prone because you must sync number in the mixin and in the app.view..).
...
I need more time for exploring. (I'm at work.)

Btw hyperapp-fragment is not about components. It's just about scoping and separating unique(!) parts of the app. It cannot be used for multiple calls in the app.view (I sadly must to say).

[Pyrolistical]

Sorry, but what is HoF?

[rqrqrqrq]

High order function.

Btw i don't expect containers from elm-inspired framework. Elm teaches us to use only functions, not components, even for markup we need to reuse. More at https://guide.elm-lang.org/reuse/

[naugtur]

While it's clean to use and works via a single reference to container, it's still stateful components and if you ask me I wouldn't want to use it in an app I'd later have to support.
State in components is sometimes a simpler solution in react+redux (feels bad anyway) but with close to no boilerplate in hyperapp, I don't believe I'd ever need to encapsulate state here and there.

[jorgebucaran]

@Pyrolistical Nice work! If you find that this pattern works for you in an app-specific basis, sure, why not give it a shot? It's completely up to you and I have no right to tell what to use or not.

While I have no plans to support stateful components in core, I enjoy seeing all these clever patterns flourish around HyperApp's single state tree limitations.

[Pyrolistical]

ah ha, state slices solve this problem