Typing helper¶
This utility module contains one tool: the Typing
class. It is internally used in the <send/edit/delete>_message
functions of NioBot
, but you can use it at any point to send typing events to the chat.
Usage¶
Context manager to manage typing notifications.
Parameters:
Name | Type | Description | Default |
---|---|---|---|
client
|
NioBot
|
The |
required |
room_id
|
str
|
The room id to send the typing notification to |
required |
timeout
|
int
|
The timeout in seconds |
30
|
persistent
|
bool
|
Whether to send a typing notification every |
True
|
Warning
Nesting Typing
instances for one specific room is a bad idea, as when each instance is exited, it stops typing
for the given room. For example, the below will not work as expected:
from niobot import NioBot, utils
bot = NioBot(...)
@bot.command()
async def ping(ctx):
async with utils.Typing(ctx.client, ctx.room.room_id):
await ctx.respond("Pong!")
bot.run(...)
This will not work because Context.respond
calls NioBot.send_message
, and NioBot.send_message
creates its own
Typing
instance.
Once ctx.respond
returns, the internal Typing
instance is destroyed, and the typing event is stopped, as is
the behaviour of exiting the context manager. This means that either
if on the loop, the upper-most utils.Typing
instance will simply just create a new typing notification,
or will not (especially if persistent
was set to False
). This breaks the whole persistence of typing.
If you want to use Typing
to show that you're processing something:
If you want to use Typing
to show a user that your bot is "thinking", or similar, you should make sure you
exit the instance before responding. For example:
from niobot import NioBot, Typing
import httpx
bot = NioBot(...)
@bot.command()
async def process(ctx):
"""Spends a worryingly long time making a network request."""
async with Typing(ctx.client, ctx.room.room_id):
await httpx.get("https://example.com")
await ctx.respond("Done!")
Be aware that this will cause a momentary blip in the xyz is typing
status, but this is unavoidable, simply
due to the semi-stateless nature of this context wrapper
A potential future solution would be to implement some funky internal lock mechanism and/or just prevent
nested Typing
instances, but this is not a priority at the moment.