Summary

use sphinx for documentation

What is the feature request for?

The documentation

The Problem

no docs

The Ideal Solution

docs

The Current Solution

none

Additional Context

would be cool, maybe even nice

Summary

Add the documentation as a hyperlink in the readme

What is the feature request for?

The documentation

The Problem

None

The Ideal Solution

First of all, I'm talking about this documentation page: https://disnake-ext-components.readthedocs.io/en/docs/
This could be done in many ways but the most simple one would be to add it as a hyperlink like so:

disnake-ext-components

An extension for disnake aimed at making component interactions with listeners somewhat less cumbersome.
Requires disnake version 2.5.0 or above.

Documentation

The Current Solution

No response

Additional Context

No response

Description

A way to assign a callback to always listen for components matching certain attributes.

eg, a button the button colour and custom_id, and the fact that it is a button

@components.match_component(disnake.Button(custom_id="button!", color="..."))

@components.match_component(component_type=disnake.ComponentType.button, custom_id="...")

This effectively allows a button callback.

To make this even nicer, using the decorated function could have a method or function attached that creates a component with the specified parameters, as that would allow sending the created and matching button or select quite easily.

Summary

Use a custom dataclass solution instead of attrs.

What is the feature request for?

disnake.ext.components

The Problem

Currently, the lib (rewrite) uses attrs to generate its parser classes. The resulting classes can do a lot more than strictly necessary. By creating a custom dataclass-like implementation, we can cut down on a lot of functionality we do not need, and considerably simplify class creation logic (just take a look at how convoluted the component metaclass is).

An example of this is field metadata. Currently, any specialised data is stored in attrs fields' metadata. This is an immutable mapping (types.MappingProxyType). Therefore, to update the metadata, one would need to create a copy of the field and overwrite the existing one with the copy. A custom implementation would allow us to control when this data is frozen, considerably simplifying the instantiation logic.

Due to the heavy-handed nature of this suggestion, it is of very low priority. Our main concern at this moment is making sure the rewrite is feature-complete, and any refactors like this can come after.

The Ideal Solution

Create a fully customised dataclass-like implementation. First and foremost, custom fields that natively support everything components need (e.g. built-in parser support). After that, a modified component metaclass that handles these custom fields in such a way that the resulting "API" remains compatible with the existing one.

The Current Solution

No response

Additional Context

This is of very low priority. We shouldn't bother with this until at least after the library is feature-complete.

• bug report
• feature request
• any others

Summary

A couple rather handy parameter types such as List[T] are not yet supported outside of special parameters.

What is the feature request for?

disnake.ext.components

The Problem

Currently, to convert input to e.g. a list of values, one would need to make a custom converter using components.Converted. It would be nice to innately support a variety of collection types by default. Furthermore, certain disnake types such as disnake.Colour and disnake.PartialEmoji are not yet supported either.

The Ideal Solution

Implement support for these missing types.

The Current Solution

Writing custom converters using components.Converted; e.g.

def to_list(arg: str) -> typing.List[str]:
    return arg.split(",")

def from_list(arg: typing.List[str]) -> str:
    return ",".join(arg)

# annotation:
components.Converted[
    components.patterns.STRING,  # not really any regex validation
    to_list,
    from_list,
]

Additional Context

No response

Summary

Add logging to e.g. custom_id creation such that it is easier for people to figure out if something went wrong and why.

What is the feature request for?

disnake.ext.components

The Problem

Currently, just about everything the module does, happens internally, away from the user's influence except for any exceptions that are raised. Providing logging for some internal actions that are taken would make it easier to debug any issues. This holds both for fixing bugs with the library, and for the end-developer to more quickly figure out if something went wrong due to an error they made in setting up the component listeners.

The Ideal Solution

Add logging debug logging to a couple parts of the internals. Ideally use different loggers so users can pick which they want to enable/disable. of

The Current Solution

There currently is no solution to this problem, outside of writing custom listener classes, which is not really feasible.

Additional Context

No response

Summary

Add parser classes for a bunch of disnake classes that should have them.

What is the feature request for?

disnake.ext.components

The Problem

Currently, the types supported by disnake-ext-components' parsers are

• builtin types, such as str, int, float, bool, etc.;
• all types defined by the standard-library datetime module;
• disnake basic snowflake types (abc.Snowflake and Object; both map to Object);
• all disnake channel types.

This means that a lot of types that should have parsers currently do not. This means that type annotations for custom id parameters with these types will not work, and raise an exception instead. It is therefore desirable to implement more types. These missing types include:

• disnake.User/disnake.Member;
• disnake.Guild,
• disnake.Message and disnake.PartialMessage;
• disnake.PartialMessageable (Note, this one may need some special attention);
• disnake.Role;
• disnake.Emoji and disnake.PartialEmoji;
• disnake.Permissions;
• all disnake Flags (a singular FlagConverter set as default for all flag types should do the trick);
• probably some others I forgot about.

Similarly, there's some other standard-library types that could do with parsers:

• enum.Enum and enum.Flag;
• ...?

Given the large scale of this issue, it is perfectly fine and much appreciated even to contribute only a small bit of the missing parsers and we'll tackle all the types over time.

The Ideal Solution

Implement parser classes for the aforementioned types.

The Current Solution

Writing custom parsers for all these types. While this is possible right now, it's not sufficient in the long-term.

Additional Context

No response

Summary

Add string compression for custom ids, such that users can store more data than normally allowed by discord's 100-character limit.

What is the feature request for?

disnake.ext.components

The Problem

Discord enforces a maximum length of 100 characters for their components' custom ids. Since ext-components stores data in these custom ids, it is feasible to run out of space. It would be nice to provide the user with hooks with which they can (de)compress custom ids with a compression lib of their choice.

The Ideal Solution

Provide users with hooks to (de)compress custom ids. Provide a 'default' library through installation of e.g. disnake-ext-components[compress]. This default library will probably be python bindings to unishox-2: unishox2-py3, as this can handle the complex nature of custom ids an d still provide compression.

note: discord only cares about text-length, not byte length, which we can make optimal use of with this lib.

The Current Solution

Currently, the only way to make use of compression would be to use a custom converter on each callback parameter to individually compress them. In many situations, this would barely provide any gains.

Additional Context

This should come paired with proper length checks for created custom ids.

Summary

Rewrite parsers to be actual class definitions instead of generated shorthands.

What is the feature request for?

disnake.ext.components

The Problem

Currently, a bunch of parsers are generated by means of a _build_<type>_parser helper function and some parameters to make them work as intended. This doesn't play nice with typehinting (we can't modify typehints on a per-parser basis) and documentation, so we should use explicit class definitions for all parsers.

The Ideal Solution

Replace all "functional" parser definitions with actual classes.

The Current Solution

No response

Additional Context

This is especially relevant given upcoming changes moving away from requiring an interaction to parse a component.