chore(server): easy js to ts migrations #2 - objectStorage.ts #3396
Conversation
| } catch (err) { | ||
| if (err instanceof S3ServiceException && err.Code === 'NoSuchKey') | ||
| if (err instanceof S3ServiceException && get(err, 'Code') === 'NoSuchKey') |
There was a problem hiding this comment.
get(err, Code)
no such prop according to TS, hence the dynamic access
| @@ -51,32 +61,45 @@ const getObjectStorage = () => ({ | |||
| createBucket: createS3Bucket() | |||
| }) | |||
|
|
|||
| const sendCommand = async (command) => { | |||
| const sendCommand = async <CommandOutput>( | |||
There was a problem hiding this comment.
ok, nice use of generics. I think this is where I got stuck!
There was a problem hiding this comment.
I notice that when sendCommand is called we don't specify what CommandOutput is. Is it inferred from the usage?
| return await client.send(command(Bucket)) | ||
| const ret = (await client.send( | ||
| command(Bucket) as Command<any, any, any, any, any> | ||
| )) as CommandOutput |
There was a problem hiding this comment.
I'm not a fan of as CommandOutput. Is there a safer way of doing this?
There was a problem hiding this comment.
It's already as CommandOutput in practice, the type of CommandOutput is auto inferred from the actual command you pass in. The only reason I need to do this is because of all of the abstraction and generics behind the scene which break something - I dunno, it wasn't obvious to me how to avoid it.
Description & motivation
Changes:
To-do before merge:
Screenshots:
Validation of changes:
Checklist:
References