hyperapp: app returning state or destroy(kill) func?

Hyperapp#2 app should return something useful to dev userland, several options:

emit app state changes, can be useful when you don’t have any possibility to add subscription directly to the app: custom elements, etc

const onStateChange = app(props)
onStateChange(state => {
  // do your external state magic
})

return kill function. After ‘app’ purity discussion, we came that modifying dom is a side effect, and should be implemented as internal subscription, as result - ‘kill/destroy’ function is a trigger to unsubscribe all the app subscriptions

const kill = app(props)
onExternalChange(() => kill()) // pass new state/reason as arg?

For performance and memory reasons I would go with 2, but 1 can be quite useful too, any suggestions?

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 21 (21 by maintainers)

Most upvoted comments

@sergey-shpak I prefer your (2) suggestion. Rather than onStateChange or even using a subscription, I suggest using middleware to synchronize your state to local storage.

jorgebucaran on Jul 29, 2019

@jorgebucaran or even shorter

function unsubscribe(){ patchSubs(subs, [], dispatch = function(){} ) }
return function kill(s){ return s === state ? [s, [ unsubscribe ]] : dispatch(kill) }

and now ‘kill’ action is visible to devtools, and then self-destroying becomes possible

const kill = app({
  view: state => <button onclick={ kill } >kill</button>
})

🚀 🚀 🚀

sergey-shpak on Jul 27, 2019