Better Async Effects

[rmorshea]

_{By submitting this pull request you agree that all contributions to this project are made under the MIT license.}

Issues

Closes: #956

Solution

Async effects now accept a "stop" Event that is set when an effect needs to be re-run or a component is unmounting. The next effect will only run when the last effect has exited.

@use_effectasyncdefmy_effect(stop):
... # do workawaitstop.wait()
... # do cleanup

Implementing this same behavior using sync effects is quite challenging:

importthreading, asynciofromreactpyimportuse_effect, use_refdefuse_async_effect(func):
thread=use_ref(None)
@use_effectdefmy_effect():
ifthread.currentisnotNone:
# wait for last effect to completethread.current.join()
loop=stop=Nonestarted=threading.Event()
defthread_target():
asyncdefwrapper():
nonlocalloop, stoploop=asyncio.get_running_loop()
stop=asyncio.Event()
started.set()
awaitfunc(stop)
asyncio.run(wrapper())
# start effectthread.current=threading.Thread(target=thread_target, daemon=True)
thread.current.start()
started.wait()
# register stop callbackreturnlambda: loop.call_soon_threadsafe(stop.set)

To achieve this without requiring an implementation similar to the above, we've asyncified the internals of Layout. This has the side-effect of allowing other things to happen while the Layout is rendering (e.g. receive events, or allowing the server to respond to other requests). This potentially comes at the cost of rendering speed. For example, if a user is spamming the server with events renders may be interrupted in order to respond to them.

Checklist

• Tests have been included for all bug fixes or added functionality.
• The changelog.rst has been updated with any significant changes.

[Archmonger]

This interface should be relatively similar to the use_messenger hook we designed.

Notes

• We should timeout the effect if it takes too long to teardown
• A 2 second timeout is a good default for most situations.
• Needs a teardown: Coroutine parameter in the hook

importasynciofromreactpyimportcomponent, use_effect@componentdefexample():
asyncdefteardown():
...
@use_effect(timeout=2, teardown=teardown)asyncdefexample_effect(cancel: asyncio.Event):
whileTrue:
awaitsomething("my-message-type")
...
ifcancel.is_set():
break

[rmorshea]

Needs a teardown: Coroutine parameter in the hook

I think this is a slight simplification - teardown should just happen after the stop event is triggered.

@use_effectasyncdefeffect(stop):
# do effectawaitstop.wait()
# cleanup

We should timeout the effect if it takes too long to teardown

I thought about this for a bit and realized that a simple timeout parameter is ambiguous - does it apply to the effect creation or cleanup. I'd rather not complicate it with more parameters. Adding a timeout is also quite easy:

awaitasyncio.wait_for(task(), timeout...)

[Archmonger]

teardown should just happen after the stop event is triggered.

This can't always occur though. For example, in the case of the user closing their browser window. We need a timeout to cover edge cases like this.

a simple timeout parameter is ambiguous

We can call it exit_timeout, cancel_timeout, or stop_timeout

Adding a timeout is also quite easy:
await asyncio.wait_for(task(), timeout...)

What you proposed isn't equivalent to a stop_timeout.

[rmorshea]

Both comments seem to address the fact that we might want to enforce a timeout when a connection is closed. That seems reasonable, but in that case, it seems better to introduce that timeout here when a Layout is exiting:

reactpy/src/py/reactpy/reactpy/core/layout.py

Line 75 in c311345

awaitself._unmount_model_states([root_model_state])

Though, even without this, the user could enforce a "stop timeout" themselves if they wanted:

awaitwait_for(create_effect(), timeout=...) # creation timeoutawaitstop.wait()
awaitwait_for(cleanup_effect(), timeout=...) # cleanup timeout

[rmorshea]

So thinking through our interface some more I'm realizing that:

@use_effectasyncdefmy_effect(stop):
task=asyncio.create_task(do_something())
awaitstop.wait()
task.cancel()
awaitfinalize_it()

Is not correct since simply cancelling a task does not mean that it will have exited by the time finalize_effect starts running. The correct implementation would actually be:

@use_effectasyncdefmy_effect(stop):
task=asyncio.create_task(do_something())
awaitstop.wait()
task.cancel()
try:
awaittaskexceptasyncio.CancelledError:
passawaitfinalize_it()

This is far too complicated for users to understand.

As such, I've done some thinking and realized that in 3.11 asyncio got some interesting new features that would allow the above to be implemented with this instead:

@use_effectasyncdefmy_effect(effect):
asyncwitheffect:
awaitdo_something()
awaitfinalize_it()

The behavior is that awaitables within the body will be cancelled if they have not completed by the time the effect needs to stop. The body will also pause until the effect needs to be stopped, thus allowing you to perform finalization after exiting the body. If you want to implement a "fire and forget" effect, then you simply ignore the body and do not enter it.

The implementation of the effect context manager would look something like:

classAsyncEffect:
_task: asyncio.Task|None=Nonedef__init__(self) ->None:
self._stop=asyncio.Event()
self._cancel_count=0defstop(self) ->None:
ifself._taskisnotNone:
self._cancel_task()
self._stop.set()
asyncdef__aenter__(self) ->None:
self._task=asyncio.current_task()
self._cancel_count=self._task.cancelling()
ifself._stop.is_set():
self._cancel_task()
returnNoneasyncdef__aexit__(self, exc_type: type[BaseException], *exc: Any) ->Any:
ifexc_typeisnotasyncio.CancelledError:
# propagate non-cancellation exceptionsreturnNoneifself._task.cancelling() >self._cancel_count:
# Task has been cancelled by something else - propagate itreturnNoneawaitself._stop.wait()
returnTruedef_cancel_task(self) ->None:
assertself._taskisnotNoneself._task.cancel()
self._cancel_count+=1

[Archmonger]

Is there any way for us to use Python 3.11 asyncio features in older versions?

I'm pretty sure the answer is no, and if so what do we want to do in the interim while we wait for 3.11 to become our minimum version?

[rmorshea]

I'll have to play around with whether this can be achieved with anyio. It may be possible.

[Archmonger]

If we're going to introduce async specific use_effect parameters, we might want to separate async effects into their own hook.

Such as use_async_effect.

[rmorshea]

@Archmonger I'm encountering some issues with lxml during installation. I fixed a similar issue by installing setuptools but that doesn't seem to be helping.

Limiting the default python version to 3.11 seems to have fixed it.

[rmorshea]

I'm going to close this and break up the changes into two parts:

1. Concurrent renders
2. Async effects.