Skip to content
This repository has been archived by the owner on Jun 9, 2022. It is now read-only.

v3 #21

Open
bjartek opened this issue Oct 17, 2021 · 3 comments
Open

v3 #21

bjartek opened this issue Oct 17, 2021 · 3 comments

Comments

@bjartek
Copy link
Owner

bjartek commented Oct 17, 2021

Plans for v3 are:

Refactors:

  • control what env to deploy to using an ENV var if you use gwtf.NewGoWithTHeFlowFromEnv
  • read in transactions/script and parse them so that we know the name of the arguments
  • create a subbuilder under Script/Transaction Arguments that unite all the arguments code
  • make Arguments Key Value pair to make it easier to avoid mistakes. (order the arguments in the correct order based on what is in the script/transaction)

New Features:

Maybe:

  • generate go code from transactions/scripts that are typed correctly.

Integrate as much as gwtf into flowkit

@louisguitton
Copy link
Contributor

louisguitton commented Nov 30, 2021

Really exciting stuff here. Here are three things that threw me off a little with v2 which maybe could be easy fixes as part of v3 (bare with me as go is not my main language):

Refactors:

@bjartek
Copy link
Owner Author

bjartek commented Nov 30, 2021

Really good points!

The plan for setting up GWTF is to use a builder style pattern and I can include options to override the hardcoded paths.

The reason the test files have to be in the root folder is also in order to have access to a flow.json file that is in that same folder, but if we add a builder option for that it would solve that issue as well.

@0xmovses
Copy link

Thanks for this awesome tool Bjartek, the key value pairs would be a great addition. I was imagining something like this, (I'm from JS land), or some variation of this...

output := flow.TransationFromFile = {
   UFix64 : 100.00,
   SignProposeAs: "first",
   AccountArgument: "second"
}

I think it would perhaps be more intuitive if when passing arguments for transactions or scripts, the type matches the type in cadence whereas currently it always requires a string. For example:

UFix64Argument("100.00") could instead be UFix64Argument(100.00) this means the code will be more understandable at a glance as the go syntax highlighting will be in full force. This would also be nice as you could pass in dynamic variables of types other than a string. If they do not match the type required, an error for this case.

Another awesome thing would for the emulator in memory to output what is inlog() in a transaction or script file. currently it does not, this would be helpful for more granular debugging.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants