Frontend 2.0

[luziusmeisser]

We should think about how we should move the frontend forward. Most importantly, it would be good to bring today's position page to a higher level of abstraction. It could become a "borrow" page that allows the user to comfortably borrow against a collateral detected in the users wallet.

An open question is whether managing existing positions would still be on this page or not. Could potentially be moved to a separate tab.

[samclassix]

UI/UX

• Loading Screen for loading initial application state. (BlockUpdater Component Guard)

[samclassix]

Positions UI Proposal

https://github.com/Frankencoin-ZCHF/frankencoin-dapp/blob/samclassix-develop-positions-view-ui/.dev/samclassix-202406/samclassix-202406-PositionTabs.png

UI Development under progress branch: samclassix-develop-positions-view-ui samclassix-develop-positions-view-ui

[samclassix]

Wagmi. Viem, Types, Tailwind, React, ... updated

branch: samclassix-develop-positions-view-ui commit: 8dd831b5e48912d7e9c670e7fb25ea6a0f14bba3 8dd831b5e48912d7e9c670e7fb25ea6a0f14bba3

before:
"viem": "^1.19.15",
"wagmi": "^1.4.12"

after:
"viem": "^2.13.3",
"wagmi": "^2.9.8"
"@types/react": "^18.3.3",
"@types/react-dom": "^18.3.0",

• new lockfile
• updated package
• updated node_modules
• wagmi transport with alchemy
• new alchemy api key created for app
• api key updated in app.config.ts

Testing for writeContract not tested. Will be tested in the future with sepolia chain and new UI development.

Open

[ ] always define chainId and config if you interact with wagmi v2. Take from app.config.ts -> WAGMI_CHAIN.id

[samclassix]

State update between components -> move to redux store?

What happened?

• e.g. Approving a transfer tx
• after tx confirmation (Toster Await)
• btn does not change/update state (screenshot after approving)

Updated 10.06.2024:

Also found in different components while testing. State does not update after approving and btn for approving still active, next step guarded by old state.

Components

• Positions/create
• Position/[...]/Challenge

[samclassix]

Approve max value?

Click on btn will create a tx with max spendable about. Is this wanted like this?

[luziusmeisser]

Positions UI Proposal

https://github.com/Frankencoin-ZCHF/frankencoin-dapp/blob/samclassix-develop-positions-view-ui/.dev/samclassix-202406/samclassix-202406-PositionTabs.png

UI Development under progress branch: samclassix-develop-positions-view-ui samclassix-develop-positions-view-ui

We should discuss this on Tuesday at the jour fixe in person. Having the UI react differently just based on a filter seem not very intuitive. Filters should not change how items behave. We need completely distinct views with different values in the table tailored towards the three use cases: own positions, borrow, observatory. Also, clicking a position should yield a consistent result, but we can always change the button label depending on the view.

[luziusmeisser]

Approve max value?

Click on btn will create a tx with max spendable about. Is this wanted like this?

Yes, this is intended to save gas on subsequent calls. I think for immutable and audited contracts, this is acceptable behavior.