Ryan Morshead

Probably

[Cancellation shielding](https://anyio.readthedocs.io/en/stable/cancellation.html#shielding) may be the answer to this interface question. In short, the current behavior would be maintained. That is, async effects are cancelled before the next one is executed....

Fundamentally, work being done by an effect as a result of an old render should be stopped. The main issue for users is doing so gracefully since dealing with the...

I updated the issue description here. I think we need to explore these options more deeply.

I'm not really satisfied that option (4), the one @phihos implemented, is ideal. I'm worried that, by going with that approach, we'll basically have to reinvent the wheel for every...

I've tried the above out and it seems to work.

Ok, so I did a bit more reading and I found that option (4) is an [established pattern](https://medium.com/@benjamin.botto/secure-access-token-storage-with-single-page-applications-part-2-921fce24e1b5). There are examples of server-side session managers for frameworks like [Flask via...

The scope of this issue is mostly focused on finding the best option. Not necessarily on implementing it. I'd at least like to have a prepared answer if someone asks...

I think you're right though. Most people who initially adopt IDOM are probably going to be making internal facing services that don't need app level auth.

@ajvogel, I suspect that `flask-login` might not help here unfortunately. `flask-login` would basically require solution [number 2](https://github.com/reactive-python/reactpy/issues/828#issue-1431951276). In the long-run I think we're probably going to run with solution number...