Open sideninja opened 7 months ago
The description for FLIX command should be improved, it's now:
🔨 Flow Tools
...
flix execute, generate, package
It should be something like:
🔨 Flow Tools
...
flix Execute common transactions
I would also add a new super command for flix that can be something like
🔥 Super Commands
dev Build your Flow project
generate Generate new boilerplate files
setup Start a new Flow project
exec Execute common transactions and scripts
Using flow exec transfer-token 1 0x1
for example. In any case, I wish it would be at this point way easier to send 1 Flow between accounts using CLI. It is still quite hard and FLIX should fix that, and although it sure is addressing the problem we have to make sure the integration works well.
Another subjective opinion is we shouldn't just use the word FLIX everywhere because that is a made-up word and someone new coming to Flow will have no understanding of what it means. We should always explain what you can do, like execute common transactions or scripts.
Another really improtant thing is it should work out of the box, now FLIX requires for you to have for example FungibleToken contract in your flow.json, this makes the whole process difficult, so if I have to add a new contract to flow.json to send 1 Flow I already have to know too much. CLI should have some internal logic to know how to handle FLIX, and in case flow.json doesn't specify most common contracts it should have defaults, especially for emulator network, maybe even for mainnet. In any case we should make the experience to just work.
the addresses does not have to be in your flow.json IIRC, they are fetched from one of the dependencies, but the emulator versions are probably not present here
flow flix execute transfer-flow -n mainnet 1.0 0x097bafa4e0b48eef --signer bjartek
my flow.json here has no imports, no contracts. only the signer information.
But the error message it gave me when I did not specify parameters could have been better, because it know what they are and the type. It could show that.
Yeah I think if you define the network and signer you shouldn't have an issue and should require no dependencies (if you're not on emulator), but agree error messaging could be better. And maybe an error could be added about trying to use FLIX on emulator. The naming is a question more for @JeffreyDoyle, @bjartek , and @bthaile .
I was just looking through the FLIX templates and I realized not all have at least testnet
and mainnet
defined either: https://github.com/onflow/flow-interaction-template-service/blob/master/templates/emeraldid-create-lilico-id.template.json#L21
So it's almost like there needs to be a check for the network you are trying to run and if the dependencies are no there for that network it needs to tell you that the FLIX cannot be run on this network.
@JeffreyDoyle is there any plan to make it a requirement of a FLIX to have a minimum set of networks to be included?
Networks are not hardcode, FLIX can support any network or no network. It depends on the user that generates them. The json file is self contained and does not depend on user's flow.json.
TODO
: I can add an error message if the FLIX json doesn't have dependencies defined for the network the user wants to execute against.
Local development, it is possible using FLIX, for core contracts. The user generating the FLIX json would need to add aliases to the core contract dependencies in their flow.json then generate a FLIX. This would work for core contracts. I can add emulator core contracts to the default core contracts in flixkit-go.
TODO
: Add emulator core contracts to default core contracts in flixkit-go
The bigger question:
FlIX is meant for easy of integration and reuse. By nature this doesn't work with emulator outside of core contracts. Doesn't make sense for one team to generate FLIX against emulator with their own custom contracts and try to share with external teams.
Since other teams won't have the dependencies baked into their emulator. They would have to deploy other Team's contracts and generate their own version of FLIX to get the correct dependence addresses.
I don't think we should promote using FLIX with emulator. Devs should focus on testnet and mainnet deployments and FLIX since that is the whole point of FLIX.
Added warnings to docs to give more visibility to network dependencies. https://github.com/onflow/docs/pull/459
@bthaile I understand the FLIX power comes from using it on mainnet, and that's great, I also completely agree with the value proposition in making interactions secure. The only issue I have, and if the FLIX is not the solution, that's fine, but I want to make common operations for a new developer easy. Right now, someone new coming to Flow, and starting to develop locally, will have incredibly hard time just sending 1 Flow. This shouldn't be the case. This is how you can loose developer due to frustrations. My proposal: A new developer comes, downloads CLI, can create an account with a single command (already possible), can send 1 Flow from that account to another account (and maybe 3 more common operations like that, not sure from top of the head what they are), all that without doing configuration, getting multiple pieces configured etc. If FLIX is not suitable for that, we can still just create some simple commands that do those operations (even if we hardcode some core contracts in CLI). At the end of the day, we shouldn't forget what counts the most is how easy something feels to others, not how well built something is from our perspective.
The FLIX doesn't work for very basic default setup using the Flow CLI and emulator. The experience should be that if you setup a new project and run an emulator it would be very easy to send some flow between accounts using FLIX, but now the output is:
We should also have more examples in the
flow flix execute
help section, maybe include most common interactions, the idea is you can discover things you can do without reading the docs. Another useful thing would be to update maybe the transaction help screen to include a line that says you can use FLIX for common operations.