Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Typing metadata keys' values #11

Open
Amgelo563 opened this issue Nov 24, 2024 · 0 comments
Open

Typing metadata keys' values #11

Amgelo563 opened this issue Nov 24, 2024 · 0 comments
Labels
priority: low Low priority issue type: enhancement Enhancement to an existing feature

Comments

@Amgelo563
Copy link
Member

Amgelo563 commented Nov 24, 2024

Current metadata keys work by simply returning an unknown value. We can improve this by adding typed keys, which would contain both the key and the value of the type, similar to branded types.

It'd be something like (names may vary):

declare const __keyType: unique symbol;
type KeyType<T> = { [__keyType]: T };
export type TypedKey<T> = symbol & KeyType<T>;

function typeKey<T>(name: string): TypedKey<T> {
    return Symbol(name) as TypedKey<T>;
}

This typeKey() function can be used to create keys that can only get or set values of type T:

const numberKey = typeKey<number>('myKey');

metadata.set(numberKey, 1); // ✅
metadata.set(numberKey, 'test'); // ❌ Argument of type 'string' is not assignable to parameter of type 'number'

const storedNumber: number | null = metadata.get(numberKey); // ✅
const other: string | null = metadata.get(numberKey); // ❌ Type 'number | null' is not assignable to type 'string | null'

Since maps are homogeneous, this would only be enforced at the metadata's get/set, not on the backing map.

This would also be helpful to remove #getBot() methods from metadata objects, making them completely independent from the framework, which would be useful to make other components independent as well like EventBuses.

@Amgelo563 Amgelo563 added type: enhancement Enhancement to an existing feature priority: low Low priority issue labels Nov 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: low Low priority issue type: enhancement Enhancement to an existing feature
Projects
None yet
Development

No branches or pull requests

1 participant