Docs about async event handlers recommand the asyncio API instead of Workers

[pthebaul]

Current text and code:

Network access is a common cause of slow handlers. If you try to retrieve a file from the internet, the message handler may take anything up to a few seconds to return, which would prevent the widget or app from updating during that time. The solution is to launch a new asyncio task to do the network task in the background.

async def on_input_changed(self, message: Input.Changed) -> None:
    """A coroutine to handle a text changed message."""
    if message.value:
        # Look up the word in the background
        asyncio.create_task(self.lookup_word(message.value))
    else:
        # Clear the results
        self.query_one("#results", Static).update()

As Will said on Discord:

It is still true, but if would definitely be a good place to induce workers!

[github-actions]

We found the following entries in the FAQ which you may find helpful:

• How do I fix WorkerDeclarationError?
• Why do some key combinations never make it to my app?

Feel free to close this issue if you found an answer in the FAQ. Otherwise, please give us a little time to review.

This project is developed and maintained by Will McGugan. Consider sponsoring Will's work on this project (and others).

This is an automated reply, generated by FAQtory

[fancidev]

Indeed workers would be better since it handles cancellation automatically when the widget is no longer used. In addition, asyncio's documentation says the return value of create_task must be assigned to a variable to prevent the task from being garbage collected prematurely, so the demo code is not completely robust.