Specify Operation types #19
Conversation
…uping.py, ipexing.py, notifying.py, exchanging.py
| oobi: string; | ||
| }; | ||
| OOBIOperation: { | ||
| name: string; |
There was a problem hiding this comment.
Right, I do see the issue with discriminating by unions when you get or list operations. The type of an operation is embedding in the name (e.g. witness.<aid>) but this is not very useful in TypeScript. We could extend the operation type to have a specific type.
So expose Op.type in Operation in KERIA - that would be a backwards compatible change which would be useful for this maybe?
| op.metadata.depends && | ||
| typeof op.metadata.depends === 'object' && | ||
| 'done' in op.metadata.depends && | ||
| op.metadata.depends.done === false |
There was a problem hiding this comment.
I see some issues below with depends. depends, if provided, is always another operation, so we should not need to cast it or check these. I see some places below where we have depends pointing to KERI events etc
| increaseFactor?: number; | ||
| } = {} | ||
| ): Promise<Operation<T>> { | ||
| ): Promise<Operation> { |
There was a problem hiding this comment.
I see this is very problematic below. Is there any way to determine if we give a particular operation, we get that one back...?
Maybe we need an overload for each operation. Like wait(op: OOBIOperation, ..): Promise<OOBIOperation>
There was a problem hiding this comment.
We want to avoid making our lives very very hard in applications that use this library where we need many casts and checks everywhere.
Sotatek-Patrick-Vu
force-pushed
the
feat/common_type_hints
branch
from
03c8796 to
a9d1ad5
Compare
No description provided.