Stopping Apps!

[zaceno]

Thought I would try using GitHub's new discussions feature to talk about stopping apps (we already talked about it in #873 and on slack – so why not one more place 😉 )

Last we spoke I recall you said you would bump the priority on #873 . I know that user-facing API is more important than implementation, but just to recap what the implementation entails it is just about adding:

 return function () {
   patchSubs(subs, EMPTY_ARR, dispatch = Function)
 }

to the bottom of the app function. This does two things:

• it turns off all subscriptions. Significantly, it does so without trying to render the view one last time. This is important because in cases where the parent node or root node has become disconnected from the DOM there could be runtime errors otherwise
• It disables dispatch. This is important becasue the app could have asynchronous effects pending, about to dispatch an action with some data being fetched from a server for example. If we don't disable dispatch, it could make the app come alive again (or at least cause errors)

Notably, this does not in any way try to "clean up" the DOM, removing the app's nodes. That is intentional. You might want the DOM left intact in order to do some further manipulation with it (to animate it floating away for example), or the DOM might already have been disconnected so trying to fiddle with it would cause errors. Anyway, if you do want to clean up the DOM, that's easy enough for the user to implement themselves.

The fact that we leave the DOM alone is another reason for dispatch = Function (disabling dispatch). It means that all DOM event handlers, while still attached, can't actually make anything happen. The alternative would be to walk through the DOM and remove all handlers.

The use case I am currently working on, where I need this and cannot find a way to solve the problem without this, is an "app gallery": a demo app where you can have one of several apps running at a time, and switch between them using a menu.

A less edge-casey scenario where this could be necessary is when you are "incrementally adopting" Hyperapp: You have a large app written with some other framework, and rather than rewriting all of it to Hyperapp in one go, you want to replace piece by piece with little hyperapps (until everything is Hyperapp and they can be merged).

[zaceno]

@jorgebucaran Said on slack:

It's unfortunate that we can't somehow reuse our existing architecture to do this.

@zaceno replied:

Yeah, I suppose dispatch=Function could be managed in userland via middleware. The main issue is the extra render that is unavoidable when trying to stop all subscriptions from userland.

Maybe now since the app won’t start if the state is nullish, we could say that dispatch(undefined) is equivalent to “stop”? If, internally hyperapp would stop all subs without an extra render, then I think we could use middleware to implement a proper kill func

[zaceno]

Although this could work, I feel like it would be proper for hyperapp to ship with the ability to clean up after itself. It's not what middleware is for, really. And relying on users knowing how to implement it properly.

[jorgebucaran]

Is there are prior art to this?

[zaceno]

Yeah don't know why so silent. Maybe it's related to the community issues I've been hearing about.

[zaceno]

In mithril, you clean up by: m.mount(element, null) (note the null where you would have a component to start an app)

[zaceno]

Given how every other framework has this problem solved it's weird that Elm does not.

[zaceno]

Knockout: ko.cleanNode(element)

[zaceno]

Returning a function to stop the app, from the function that starts it, would be symmetrical with Hyperapp's own subscriptions api where subscription functions are called to start, and return the function to stop them.

[zaceno]

Is there anything I can do to move this forward? More research on how others do it? Some alternative PoC to #873?

[zaceno]

The example above seems to work fine, but I'm having some issues with that approach in my local, more complex app. Need to investigate further.

[zaceno]

Ok for some reason it wasn't enough to avoid enqueuing renders when the app is stopped (when the timing constraints are tight, so probably somthing to do with how stuff is scheduled). . This seems 100% solid.

All I did was add state!==undefined && to the beginning of line 412. That allows me to implement a solid stopper in userland. Of course I would prefer to have #873 merged, but if we don't want to introduce a new api, this change is the next best thing as it is backward compatible and enables userland stop-implementation

[jorgebucaran]

Won't this make it harder (or impossible) to start an app with an undefined state?

[zaceno]

@jorgebucaran afaik it already is

[zaceno]

But yes you are correct. And I don't think this is ideal. But you asked me to explore ways to fix this without adding a new api and this is the best I could come up with 😉 🤷

[jorgebucaran]

The alternative would be to walk through the DOM and remove all handlers.

Just removing the root node would suffice. No need to tear down each individual room if you are going to demolish the building.

[zaceno]

But I might want to keep the dom around. Not sure why exactly but who knows what might come up.