use-ink / contracts-ui Goto Github PK

The instantiation and call pages will need a component that can handle any type of argument passed into a contract's constructors or methods, analogous to @polkadot/react-params. For any unsupported data types, the input should be a text field for the hashed hex value.

Absolutely essential data types for v1:

• Boolean
• Number
• Balance (should be already mplemented for contract instantiation)
• ...

Messages that change the contract storage when called are payable, therefore they should be sent as transaction with contract.tx. For example inc() in incrementer
Messages that only retrieve information from contract storage, are not payable and can be sent as RPC call with contract.query. For example get() from flipper

Why is user selection necessary in this case? Can the user send a payable message as RPC call and viceversa?

@erler @kwingram25

It should:

• run the build automatically for every new commit pushed in any branch
• run lint and test stages after the build
• display a test coverage badge
• protected master branch
• minimum 2 reviewers approve PRs
• disallow merge to master for branches that do not pass lint and test
• display test coverage for in PR, disallow merge if coverage is less than master branch

Add and configure tailwind with all the needed extensions

to be discussed

After reviewing PR43 i wanted to switch to another branch
Did yarn deep-clean && yarn && yarn start and got a white screen and this error in google chrome console, but no build errors

After a google search on the error, it seems to be related to localStorage, which i cleared but the problem persisted.

App-wide Notification system.

Styles for things like buttons, borders, inputs, colors, breakpoints, typography etc. should be predefined and reusable.
Ideally, base styles should be composed in a stylesheet by extending tailwind classes, not inline in components.

The UI should display return values of transactions which are submitted.

The v1 does this only for RPC, v2 should also display them for transactions. Due to the asynchronous nature of transactions it might be best to display them as a notification

Overview

User accounts will allow users to

• Claim ownership of contracts and code bundles they uploaded
• Favorite contracts/code bundles
• Integrate with ink! playground authored elements (tbd)

The user account doubles as a Textile identity allowing interactions with ThreadDB's remote features (pushing to and pulling from the IPFS database). In case an account is not connected, a generic randomly generated identity will be used strictly to allow fetching remote data.

Sign in process

(adapted from https://docs.textile.io/tutorials/hub/pki-identities/#metamask)

• From the sidebar, user clicks Connect Account to open a dialog
• User selects one of their Polkadot accounts from a dropdown and enters a secret (password) to generate their identity
• The app then creates a unique string that contains a hashed version of the secret, the app name (canvas-ui), and some additional text. The app can regenerate this string at any time in the future if the user supplies their secret. example
• The unique string is then signed with the user's Polkadot address via the extension. (example)
• The resulting signature is used to generate an ed25519 key that can be used as an identity with all Textile APIs. User can then edit their displayed name, add optional fields like email address, etc. to be stored in User collection

This approach allows the user to retain access to their identity and saved contracts etc. as long as they still have access to the Polkadot account and the secret they used. The last used identity can be saved in localStorage to prevent the need to connect on every page load. The account dropdown can be used to switch between previously used identities.

Once signed in, all contracts the user uploads will be associated with their identity and displayed under "My Contracts" on the sidebar and elsewhere. They will be able to favorite/"star" code bundles and contracts uploaded by others.

Claiming on-chain items

Even if a user was not signed in, the database will record the Polkadot account that was used to instantiate or upload each item on the chain. Once they are signed in, users can claim unclaimed contracts or code bundles by signing a unique message with the Polkadot account that was used, and the contract/code bundle will then be associated with their identity.

Prod bundle is too big, enable gzip and research best practices for webpack 5
Maybe speed up build time as well
https://webpack.js.org/guides/build-performance/#typescript-loader

Update Readme file with better description of the project for contributing developers
Create user manual from a smart contract dev perspective

contract page should display

• the name of the contract
• which bundle was instantiated from and by whom (not sure that's MVP though)
• a "tabs" component below the title with 3 empty sections (metadata, interact, storage)
• a column on the right for the call results when the interact tab is active

the interact functionality is almost done
the scope of this issue is just to have the layout ready
separate issues for each tab and call results display

functionality is done with local storage
how will it integrate with the new db? @kwingram25

to do:
write tests
add styling
add name input
add salt and gas components (currently hardcoded)

Mocking complex objects like ContractPromise, ApiPromise, Abi etc. has proven to be difficult with traditional jest mocking techniques.

An investigation of how better to test code that uses this kind of objects is necessary.

Starting point: how @polkadot/apps is doing it

The new app should have a staging env. This means we need to host it somewhere more advanced than github pages

the app should be deployed automatically to corresponding env immediately after a new feature or branch has been successfully merged (master -> staging, production -> production)

ideally, production-like environments should be created for PRs for easy manual QA

these are possible solutions:
https://www.heroku.com/home
https://www.netlify.com/
others?

i was thinking to move everything in src/ui/components up one level so that we have:
src/ui/instantiate
src/ui/contract
src/ui/pages
src/ui/router
on same level with contexts, hooks, templates

after the move, components that currently live in the root of src/ui/compoents like Dopdown, Input, etc. can be also moved to a new folder

if you move or rename a file alongside other changes, git displays the whole file as new in the diff, making reviews tricky
since it's about moving files around this should be a separate PR

A solution for a copy button should be found, to be applied for

• contract addresses
• code hashes
• call results

Design missing for addresses and code hashes in Figma, but quite useful. @erler was the omission intentional?

Examples from old Canvas UI:

Page layout including Tailwind classes should be extracted to reusable templates as was originally done in #43

The helpbox is not displayed on homepage anymore.

currently build is not triggered on change

The gas component should be used in instantiation and contract calling

Index / landing page with list of contracts

Although tests pass, there is this error while running unit tests

This error has appeared a while ago and was not fixed with #47
Also mentioned in #52, but apparently not related to the white screen situation.
Hopefully will be fixed with #69

Instead of functions for each DB query, consider using singleton class with the ThreadDB instance and identity as class members

Ideally, CI should not pass if

• there are lint warnings
• there are test errors but tests pass
• test coverage is reduced compared to master

This is not happening at the moment. Open for discussion, of course

large issue that should not be handled in a single PR

should be split into:

• display messages dropdown + basic call
• display decoded results
• implement account selection
• implement gas - issue link
• implement endowment
• implement query/transaction selection

After instantiation (with hash), contracts are stored in local storage.
The contract interaction also retrieves contracts from local storage.
Since the new db is ready for usage, it should be used instead of local storage.

Follow-up to paritytech/substrate#9276:

UIs should switch from consumed_weight to required_weight for gas estimation.

After calling the contract, the results are currently logged to the console.

This issue is about displaying the call results in the sidebar of the contract page according to design

there is a separate issue for the copy button, so that is not in scope #66

Currently the contract is called with Alice's account (hardcoded)

Reuse the dropdown component to call contracts as well

Each contract metadata contains all messages (or constructors) that can be called on that contract. Each message object has it's own docs property

Create a component that takes the messages / constructors as props and displays their docs inside an accordion. This component will be displayed in the metadata tab of the contract page

Part of #49

Create input component to allow passing integer values to contract messages

events and errors related to:

• transaction/signing
• instantiate
• call

reuse as much ui as possible from instantiate. (wizard, arg form, dropdown)

maybe @erler can provide more context here. not exactly clear how the layout should look

The salt is a hex or string value used to derive the address of the contract we are trying to instantiate, together with the sender address and code hash.

When the salt component is switched off, the address is derived only from sender and code hash, making the re-instantiation impossible (fails with duplicate contract error)

When the salt component is turned on, the user can pass in a string or hex out of which a new salt is encoded. If the user doesn't wish to pass in a string, a new random salt is generated by the UI, therefore the same contract can be instantiated multiple times at different addresses.

Design:

If I make a call to a smart contract which ends up reverting the UI (both the old Canvas UI and Polkadot JS App) shows some pretty unhelpful errors. See the screenshot from PJ Apps below:

Ideally we want to dig into the DispatchError and show users what the "actual" error was.

Call results should be displayed in a human form on the contract page alongside:

• the message name
• the type of the call result
• timestamp of the call

copy button has a separate issue already #66

Some contract messages require payment (endowment) in order to be called, some don't.
Some contract constructors also use this for instantiation

There should be a "payment" input field in the contract's interact tab that also functions as currency selection, when the contract call accepts endowment.

how should this look when open? @erler

also i see the currency is displayed for "message to send" dropdown as well. what does it mean?

@kwingram25 please check all of the above, not sure i understand correctly

In order to reduce noise during code reviews, prettier can be run as a pre-commit hook.
This way no accidental formatting changes can interfere with diffs.

https://prettier.io/docs/en/precommit.html

uncleared subscription to latest block generates react memory leak warning

The app should be able to switch between Canvas Test or a local node (ws://127.0.0.1:9944) from a dropdown.
Currently the app connects to a node via a connect function that lives in CanvasContext.
This function uses the “socket” property on the AppState obj that is currently hardcoded to “ws://127.0.0.1:9944”
Create a function in CanvasContext that modifies the socket property and can be called by the dropdown

The app should also be able to connect to a node rpc passed in the url
For example:
https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fcanvas-rpc.parity.io#/explorer

Possible implementation here https://github.com/substrate-developer-hub/substrate-front-end-template/blob/f9840705c9571b1bc92dc6181e6d44d093ee9fd5/src/substrate-lib/SubstrateContext.js#L12

Part of #49

Create dropdown component to allow passing boolean values to contract messages

Since we are no longer using Next.js, we need to come up with a routing solution.

Possible pages MVP:
/
/contract/[addr]
/add-contract
/add-contract/existing-code
/add-contract/new-code
/settings

The update metadata button on the contract page should update the docs accordion above it and the form displayed in the interact tab as well

It is useful for re-instantiation to be able to copy the codeHash of already deployed contracts
this will be handled in the Code Page issue #64
but for v1, something similar to old Canvas UI could be shown inside the contract card (row)

There is no description of the project, its goals, its status, or basic usage.

Per discussion