Currently, the event emitter does not support events to be asynchronous.
This restricts plugins and 3rd party consumers from unlocking the full potential of asynchronous programming.
If they wish do to do, they'll need to manually execute the async events themselves.
What I propose is to add standardized asynchronous function execution to EZ.
This should be done by first declaring that EZ runs an async loop for such uses.
Then, every time a consumer provides a callable, if it is a coroutine, it is wrapped in an object that when invoked will be executed in the async loop.
This should be used on event handlers that are registered by on and once. Note that this doesn't mean that emit should be asynchronous as well. The asynchronous nature should be hidden from consumers.
This mechanism can also be used when we stop using FastAPI, so we can support asynchronous endpoints out-of-the-box.
Another use case for this is with JSX. By having a wrapper object for asynchronous functions, we can both add support for async functions, and we don't need to add special support for it in JSX or EZ-JSX.
Since EZ is a framework, it seems acceptable that it manages the async loop. However, the async loop can be exposed to external code for cases where EZ is executed as part of another program.
neriyaco
commented
3 months ago
Currently, the event emitter does not support events to be asynchronous.
This restricts plugins and 3rd party consumers from unlocking the full potential of asynchronous programming. If they wish do to do, they'll need to manually execute the async events themselves.
What I propose is to add standardized asynchronous function execution to EZ.
This should be done by first declaring that EZ runs an async loop for such uses.
Then, every time a consumer provides a callable, if it is a coroutine, it is wrapped in an object that when invoked will be executed in the async loop.
This should be used on event handlers that are registered by
onandonce. Note that this doesn't mean thatemitshould be asynchronous as well. The asynchronous nature should be hidden from consumers.This mechanism can also be used when we stop using FastAPI, so we can support asynchronous endpoints out-of-the-box.
Another use case for this is with JSX. By having a wrapper object for asynchronous functions, we can both add support for async functions, and we don't need to add special support for it in JSX or EZ-JSX.
Since EZ is a framework, it seems acceptable that it manages the async loop. However, the async loop can be exposed to external code for cases where EZ is executed as part of another program.