feat: augmented api using @polkadot/typegen#554
Conversation
arty-name
left a comment
arty-name
left a comment
There was a problem hiding this comment.
Is there a possibility to provide sensible aliases at least for those types that we directly use in the SDK? AttestationAttestationsAttestationDetails looks funny even when you know the reason behind it.
We could do type aliasing in some file for sure, but I decided against it not only because it means maintaining more code besides what is autogenerated but also because these are the name by which these types are 'known' in the different applications and interfaces: |
| function getChainKeyTypeForDidKeyType<T extends DidKey['type']>( | ||
| keyType: T | ||
| ): ChainKeyTypeFor<T> { | ||
| return didKeyTypeToChainType[keyType] as ChainKeyTypeFor<T> |
There was a problem hiding this comment.
These two functions seems to not be necessary.
There was a problem hiding this comment.
The maps could be accessed directly instead
There was a problem hiding this comment.
it's a type thing, we want it to return a ChainKeyTypeFor
| >((obj, [key, val]) => ({ ...obj, [val]: key }), {} as any) | ||
|
|
||
| type ChainKeyTypeFor<T extends DidKey['type']> = Capitalize<T> | ||
| type DidKeyTypeFor<T extends ChainKeyType> = Lowercase<T> |
There was a problem hiding this comment.
That's super annoying. Is that necessary to be so explicit about it?
There was a problem hiding this comment.
it is, but typeof didKeyTypeToChainType[T] results in an inaccurate union type. yet another annoying TS limitation
3 participants
fixes KILTProtocol/ticket#1061
After type collision issues have been resolved with
@polkadot/apiv7 and above, we can finally start using the typegen package to provide kilt-specific api augmentation.How to test:
Checklist: