Refactor: Forwarding Path #227
Conversation
| } | ||
|
|
||
| // Return a description of the forwarding path, to be rendered. | ||
| async describe(): Promise<ForwardingPathDescription> { |
There was a problem hiding this comment.
Here I decide to use the apps that form the path but I wonder if we might need to know the whole list of installed apps. If that case we need to construct the ForwardingPath with a reference to the organization so we can fetch information like the list of apps.
|
|
||
| constructor(data: ForwardingPathDescriptionData) { | ||
| this.apps = data.apps | ||
| this.describeSteps = data.describeSteps |
There was a problem hiding this comment.
I'm still not super sure about the data structure we would like to have for the ForwardingPathDescription. I just decided to use a list of PostProcessDescription objects. Those are returned by Radspec. We may probably want to further think about it.
|
|
||
| //////// DESCRIPTIONS ///////// | ||
|
|
||
| async describeScript(script: string): Promise<ForwardingPathDescription> { |
There was a problem hiding this comment.
I decided to expose the describeScript utility to the organization as we already have all the contextual information we need and user and app connectors can leverage directly.
| @@ -0,0 +1,94 @@ | |||
| import { ethers } from 'ethers' | |||
There was a problem hiding this comment.
Here is the main logic we are currently using to both encode and decode an evm script and transform it into a ForwardingPathDescrption. I'm not convinced yet about the current data types and how we constructing the description but I think we are going in the right direction. Maybe it's a big topic and we should address it as a separate PR and further discuss it in: #219
Closes #218
Builds on #225
Note: This is still a draft PR, needs to work better on the logic of how to describe a
ForwardingPath.