Steps to reproduce

1. Upgrade to hikari 2.0.0.dev110
2. Send a message with any components
3. Try to use said components
4. Observe the components failing

Expected result

The bot should've responded to the component interaction.

Actual result

The bot didn't respond to any component interactions.

System information

hikari-miru - package information
----------------------------------
Miru version: 1.1.1
Install path: /root/venv/lib/python3.10/site-packages/miru
Hikari version: 2.0.0.dev110
Install path: /root/venv/lib/python3.10/site-packages/hikari
Python: CPython 3.10.5 (GCC 12.1.0)
System: Linux x86_64 (solar) - 5.18.16-arch1-1

Further information

No response

Checklist

• [X] I have made sure to remove ANY sensitive information (bot token, passwords, credentials, personal details, etc.).
• [X] I have searched the issue tracker and have made sure it's not a duplicate. If it is a follow up of another issue, I have specified it.

Wake up babe new pr just dropped

import miru



class MyButton(miru.Button):
    ...

class MyContext(miru.Context):
    ...

class MyView(miru.View):
    @miru.button(cls=MyButton, context_cls=MyContext, label="label")
    async def foo(self, button: MyButton, context: MyContext):
        ...
    
    @miru.button(label="label")
    async def bar(self, button: MyButton, context: MyContext):
        ...

view = MyView()

Summary

Miru should replace the current component persistence system to one thats easier to work with/possibly more efficient. I believe a side effect of my implementation will also allow custom timeout responses for buttons.

Why is this needed?

I think it is good if bots can still respond to a button after a restart.

Ideal implementation

# Internal
class ComponentInfo:
    """Info used to distinguish miru components from each other."""
    ....

# External
# The user is expected to implement these functions if they want to use persistence between restarts.

# Called when a component is created
@miru.persistence.save_component
async def save(nonce: str, component: miru.ComponentInfo) -> None:
    """Save a ComponentInfo object"""
    ...

# Called when a component nonce is received that isn't in the cachce
@miru.persistence.load_component
async def load(nonce: str) -> miru.ComponentInfo | None:
    """Load a ComponentInfo object. Return `None` if the object doesn't exist."""
    ...

# Called when 
@miru.persistence.delete_component
async def load(nonce: str) -> None:
    """Delete a component with a specific nonce."""
    ...

The internals will need to be reworked is have "registry/cache" with all the components. The nonce will be used to run the correct callback. This is similar to how crescent works so I can vouch for the system.

Checklist

• [X] I have searched the issue tracker and have made sure it's not a duplicate. If it is a follow up of another issue, I have specified it.

This is more of a suggestion, but it might make consistency between different handlers and libs for Hikari more consistent if these references were changed.

When I try to add link buttons with the following code, an error is raised and it doesn't work.

view = miru.View()
view.add_item(miru.Button(label="View Online", url=str(ctx.options.user.display_avatar_url)))
return await ctx.respond(e, components=view.build())

The issue lies in https://github.com/HyperGH/hikari-miru/blob/main/miru/button.py#L127 and causes a following error:

Traceback (most recent call last):
  File "C:\Users\User\PycharmProjects\h\iodine\lib\site-packages\lightbulb\app.py", line 994, in handle_message_create_for_prefix_commands
    await self.process_prefix_commands(context)
  File "C:\Users\User\PycharmProjects\h\iodine\lib\site-packages\lightbulb\app.py", line 966, in process_prefix_commands
    await context.invoke()
  File "C:\Users\User\PycharmProjects\h\iodine\lib\site-packages\lightbulb\context\base.py", line 292, in invoke
    await self.command.invoke(self)
  File "C:\Users\User\PycharmProjects\h\iodine\lib\site-packages\lightbulb\commands\prefix.py", line 112, in invoke
    await self(context)
  File "C:\Users\User\PycharmProjects\h\iodine\lib\site-packages\lightbulb\commands\base.py", line 435, in __call__
    return await self.callback(context)
  File "D:\Coding\Iodine\cogs\tools.py", line 41, in avatar
    view.add_item(miru.Button(label="View Online", url=str(ctx.options.user.display_avatar_url)))
  File "C:\Users\User\PycharmProjects\h\iodine\lib\site-packages\miru\button.py", line 109, in __init__
    self.style = hikari.ButtonStyle.LINK
  File "C:\Users\User\PycharmProjects\h\iodine\lib\site-packages\miru\button.py", line 128, in style
    raise ValueError("A link button cannot have it's style changed. Remove the url first.")
ValueError: A link button cannot have it's style changed. Remove the url first.

Some internal changes had to be made to make miru type-safe

Changes

• make items generic (item.view can now be given attributes)
• make @button and @select be typed to return the same function that was given
  • A possible alternative is returning the actual type, happy to hear your opinions on this one!
• added all missing typing.Any and None annotations where they were forgotten

Summary

Add readme files to most important subdirectories with short explainers detailing what can be found in the directory & directing users to helpful resources.

Why is this needed?

Because it is fancy.

Ideal implementation

Sit down and write them.

Checklist

• [X] I have searched the issue tracker and have made sure it's not a duplicate. If it is a follow up of another issue, I have specified it.

See changelog.

• no longer use explicit submodules unless they're exported
• no longer use pass where it's not needed
• ignore when 3rd party libraries are missing stubs
• for the sake of user experience assume the class is initialized when annotating
• make the colorama dependency optional (gawd the dependency management is funky)
• allow for unloading miru and stopping all views

I install hikari-miru and did python3 -m miru and it said no package named colorama, after installing, it worked fine but it didn't install with hikari-miru, so I suggest adding it as a requirement

Summary

Add short exercises to documentation to facilitate learning the different features of the library.

Why is this needed?

It helps people learn the library a lot quicker if there are potentially quick example problems to solve.

Ideal implementation

To be decided.

Checklist

• [X] I have searched the issue tracker and have made sure it's not a duplicate. If it is a follow up of another issue, I have specified it.