feat: add new JSON format for Workflows #45
Conversation
ARCHITECTURE.md
Outdated
| - **type**: Specifies a multi-send action by the application. | ||
| - **options**: | ||
| - **items**: An array of objects representing the assets to be sent, each containing: | ||
| - **asset**: An object representing the ERC20 token, or `null` for native tokens. |
There was a problem hiding this comment.
Better to make it optional
ARCHITECTURE.md
Outdated
| ```ts | ||
| const wf = workflowFactory | ||
| // Registers an action with the workflow using its type and the corresponding options | ||
| .registerAction('Application.MultiSender', MultiSenderAction) // => new MultiSenderAction(options) |
There was a problem hiding this comment.
Why do we need to duplicate type when registering? Can't we just pull it from action config?
There was a problem hiding this comment.
Yes. Good point, it could public property of Action, like MultiSenderAction.id. What do you think?
|
|
||
| ```json | ||
| { | ||
| "type": "Application.MultiSender", |
There was a problem hiding this comment.
Should we include the version?
For example we change the input parameters for an action, and user makes a call from the old version of sdk
Then it will fail deserializing on our side
There was a problem hiding this comment.
I think it will be configured via package version itself
extg3
force-pushed
the
json-workflow-spec
branch
from
fe55b2a to
122357a
Compare
| .registerAction(MultiSenderAction) | ||
| .registerTrigger(ScheduledTrigger) | ||
| // Creates a workflow from the given configuration object. | ||
| .createFromConfig(config); |
There was a problem hiding this comment.
I didn't understand why this config is needed. We already have registered actions & triggers, why do we need another config?
| abstract class AbstractAction { | ||
| static id: string; | ||
|
|
||
| abstract build(): Promise<CallDataBuilderReturnData>; | ||
| } |
There was a problem hiding this comment.
Why is interface not suitable for us?
There was a problem hiding this comment.
type BuildResult = {
callData: [],
state: any
}
interface BuildableAction {
build(provider: Provider, vault: Vault): Promise<BuildResult>
...
}|
|
||
| ```ts | ||
| class MultiSenderAction extends AbstractAction { | ||
| static id = 'Application.MultiSender'; |
There was a problem hiding this comment.
As for the ID, we may have problems with that. We want to be able to create custom triggers and actions, which means that there may be collisions with the identification of actions & triggers. In addition, it is not fully disclosed how it will be serialized and deserialized.
No description provided.