Reading/Writing Features

[DOBEN]

Purpose

closes #127

• Add a feature to read from smart contract
• Add a feature to write to smart contract

Changes

• Add a box to read from the smart contract (either the user can manually fill in all input fields of that box or the user can only input the smart contract index and derive most of the values by checking the "Derive From Smart Contract Index" checkbox)
• Add a box to write to the smart contract (either the user can manually fill in all input fields of that box or the user can only input the smart contract index and derive most of the values by checking the "Derive From Smart Contract Index" checkbox)

[soerenbf]

Here are some things to consider.

• No wallet connect support? Is this intentional or something we plan to introduce (since we use @concordium/react-components)?
• As users can now do more stuff than deploy/init contracts, it would make sense to think about user flows (in my opinion)
  • I would also introduce a router (react-router), as it lets you be more declarative about individual sections of the application, with the added benefit of persisting the location in the url along with associated state. This will allow users to use browser navigation (back/forward) to navigate the app + link to selected parts of the application, which might be useful.

Possible application routes (marked with bold)

• / (root = Deploy/declare module)
  • /module/:module-reference
    • Instantiate contract
• /instance
  • Declare contract details (can we just always derive contract name and possible entrypoints if possible?)
  • /instance/:index/read (do we need subindex?)
  • /instance/:index/write (do we need subindex?)

I realize these changes are quite substantial, but will improve usability a lot.

[DOBEN]

Makes sense. With regards to the 2-step flow, it's possible to use browser location state, which can also be restored on back/forward browser navigation.

Anyway it would be nice if you could add an issue for this refactoring 🙂

#130

[abizjak]

Looks pretty good overall.

I have some relatively minor comments.

There is one general thing about the UI, but also some details of the flows could be revised a bit.

But we don't have time to spend on fiddling with that at the moment. This can be part of the next iteration.

[soerenbf]

I still think it's worthwhile to look into the structure of these inputs that trigger other changes (effects or derived values), which is my main issue with the code as it is right now.

I would prefer if we stuck with the recommendations from the documentation of the forms library, which revolve around

• spread form.register onto input
• use Controller to integrate with controlled field components
• use validation rules and associated error messages registered
• use useWatch to handle complicated derived values or effects

[soerenbf]

Tested the different parts of the app again, and experienced this discrepancy:

If you want the concrete module deployed, I can send it to you.

Other than that, I don't have any more comments if all the optimizations with regards to using the forms library are pushed to sometime in the future.

[abizjak]

There are still some issues (see video shared in slack).

But if those are resolved I think we should merge this.

While I understand @soerenbf 's concerns, we also have to get this done.

We'll have to prioritize handling the backlog later, since we have other things we need to be working on as well. It's good there is an issue with all the concerns listed.