Containers? Yay/nay?

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?

[Pyrolistical]

ah ha, state slices solve this problem

[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.