olympusdao/olympus-frontend

Ω Olympus Frontend

This is the front-end repo for Olympus.

🔧 Setting up Local Development

Required:

• Node v16.15.0
• Yarn
• Git

$ git clone https://github.com/OlympusDAO/olympus-frontend.git
$ cd olympus-frontend

# set up your environment variables
# read the comments in the .env files for what is required/optional
$ cp .env.example .env

# fill in your own values in .env, then =>
$ yarn
$ yarn start

# Set up Husky (for pre-commit hooks) by running:
$ yarn prepare

The site is now running at http://localhost:3000! Open the source code and start editing!

Testing

We use the Vitest test driver for unit tests, snapshot tests and e2e tests.

To run tests in interactive mode during development:

yarn test
# or
yarn test --ui

Unit Testing

Unit test files are co-located with the source code files that they test and follow the naming convention *.unit.test.ts. For example unit tests for OriginalSourceFile.ts are located in OriginalSourceFile.unit.test.ts. Valid extensions for test files are .js (JavaScript), .ts (TypeScript), .jsx (React JSX), .tsx (React TSX).

To run all unit test and see a coverage report:

yarn test:unit

Note that the focus of unit testing is to exercise all paths through the code hosted in this repo and only code hosted in this repo. To the extent possible, unit tests should abstract out dependencies such as remote API calls as well as crypto wallet APIs via mock functions.

Coverage thresholds are enforced via CI checks. If a new PR introduces regression in code coverage, the CI will fail. The goal is to keep us at a minimum level of test automation coverage as we introduce new code into the repo. To see the current coverage thresholds, see the coverageThreshold in package.json.

For integration testing automation that runs browser and remote API code as well as our own code, see the End-to-end (E2E) testing section below.

Mocking Remote API Calls

Unit tests should minimize dependency on remote API calls. Remote API calls slow down test execution and they also occasionally error, which may fail tests for reasons outside the app code being tested. Live API calls should be tested in End-to-end/Integration tests.

Here is an example unit test that conditionally mocks API calls.

Generative Testing

We use fast-check for generative testing which provides property-based coverage for ranges of input values. Here is an example of a unit test case in this repo that uses generative testing.

Snapshot Testing

We use Snapshot tests to make sure the UI does not change unexpectedly. When you make changes to the UI (intentionally), you likely will have to update the Snapshots. You can do so by running: yarn snapshot.

Here is an example snapshot test and here is the correspoding recorded snapshot. Keep in mind that for snapshot tests to be meaningful, they have to pre-populate components with variety of data sets (realistic, edge case, invalid).

Here is a good blog post about testing React components with generative data sets.

React Component Testing

We use React Testing Library to test behavior of UI components. Here is an example component test. Here is a useful cheat sheet.

Mocking React Hooks

When testing components that use React Hooks to third party libraries such as React Query or Web3Provider, it is sometimes convenient to mock these hooks in order to simulate various data inputs and edge cases.

Here is an example test case that shows how to mock React Hooks that use Web3Provider and React Query APIs.

Troubleshooting

If all tests are failing in your local environment (in particular, due to a "cannot find module" error with node_modules/babel-preset-react-app/node_modules/@babel/runtime/helpers/interopRequireDefault.js), but they should be passing (and the CI tests are passing), it's likely to be an issue with your local cache. Run the following command: yarn test --clearCache

End-to-end testing

Puppeteer (with the Dappeteer addition) is used to do browser-based end-to-end testing.

To run the tests:

• Run the frontend, using yarn start
• In another terminal, run the tests, using yarn test:e2e

Architecture/Layout

The files/folder structure are a WIP and may contain some unused files. The project is rapidly evolving so please update this section if you see it is inaccurate!

./src/
├── App.tsx       // Main app page
├── abi/          // Contract ABIs
├── assets/       // Static assets (SVGs)
├── components/   // Reusable individual components
├── constants/    // Addresses & common contracts
├── helpers/      // Helper methods to use in the app
├── hooks/        // Shared reactHooks
├── themes/       // Style sheets for dark vs light theme
└── views/        // Individual Views

Theme Support

Material UI components, such as Button, can use the current theme's color scheme through the color property. For example:

 <Button variant="contained" color="primary" className="cause-give-button">
  Give Yield
 </Button>

If you wish to use a theme's color scheme manually, follow these steps:

1. Import useTheme: import { useTheme } from "@material-ui/core/styles";
2. Instantiate the theme: const theme = useTheme();
3. Add a style property to the component, for example:

 <Grid item className="cause-category" style={{ backgroundColor: theme.palette.background.default }}>
 {category}
 </Grid>

For the available theme properties, take a look at the themes in src/themes.

ESLint

We use ESLint to find/automatically fix problems.

• react-app and react-hooks/recommended are important with react stuff.
• @typescript-eslint/recommended and @typescript-eslint/eslint-recommended as recommended defaults.
• unused-imports to automatically remove unused imports.
• simple-import-sort to automatically sort imports alphabetically. This is opinionated, but useful because it helps avoid merge conflicts with imports (and who doesn't like neat alphabetically sorted imports anyway).
• @typescript-eslint/explicit-function-return-type and @typescript-eslint/explicit-module-boundary-types are turned off to prioritise inferred return types over explicit return types. This is opinionated, but often times the inference Typescript makes is good enough, and sometimes help prevents type mismatches that are a pain to debug.
• @typescript-eslint/ban-ts-comment and @typescript-eslint/ban-ts-ignore are also turned off. This could possibly be temporary, but the ability to use @ts-ignore-like directives is certainly handy as an escape hatch as we encounter errors during the migration to TS.

Reusable Components (Component Library)

Our codebase uses a custom component library extended from Material UI to make common UI patterns easy to implement on the frontend. An up-to-date list of available components, implementation examples as well as documentation is available here:

Contributions are welcome and encouraged to our Component Library. If you see repeated UI patterns not represented in the library, or would like to enhance functionality (such as adding assets to our Icon or Token components), you're welcome to submit a PR to the component-library project. Please fully review component documentation in Storybook before submitting a PR.

Code Generation

The react-query hooks for the Cooler Loans API are automatically generated from the OpenAPI typings. If changes are made to the API, re-generate the typings using yarn codegen. This has some steps in-between, as the code generators did not correctly handle referenced files and needed to bundle them together.

🚀 Deployment

Auto deployed on Fleek.co frontend by Cloudflare. Since it is hosted via IPFS there is no running "server" component and we don't have server sided business logic. Users are served an index.html and javascript to run our applications.

Continuous deployment

Commits to the follow branches are automatically deployed to their respective URLs.

Branch	URL
master	https://app.olympusdao.finance
develop	https://staging.olympusdao.finance

Pull Requests: Each PR into master will get its own custom URL that is visible on the PR page. QA & validate changes on that URL before merging into the develop branch.

Cooler Loans Dashboard

The data in the Cooler Loans Dashboard is served by an API that generates time-series data not possible in a subgraph. See the cooler-loans-api repository for details.

Different endpoints are used in different circumstances:

• Build (deployed by Fleek): production
• Local development: dev
• If VITE_COOLER_LOANS_API_ENDPOINT is specified in an environment variable, it will be used regardless

Treasury Dashboard

The data in the Treasury Dashboard is powered by subgraphs hosted by the Graph Protocol and served using GraphQL. There are a few limitations, however:

• Each subgraph can index only one blockchain, so there are subgraphs deployed for each blockchain.
• The implementation of pagination in the Graph Protocol's GraphQL server is very basic, and requires running through successive date ranges in order to piece together results.

Using infinite queries (generated by graphql-codegen), a custom paginator and custom code to combine results from different blockchains, this was previously implemented client-side. However, the code was very brittle, and sometimes suffered from stale queries.

This has since been improved by adding Wundergraph middleware (hosted on Wundergraph Cloud) that handles combining results and pagination server-side. The complete data set is then retrieved using react-query and a generated client, @olympusdao/treasury-subgraph-client.

Wundergraph Node URL

The Wundergraph client is pre-configured with the production endpoint (referred to as a public node URL).

A developer may wish to use a different endpoint during development (e.g. to test changes that are not live in production). To achieve this, prefix the yarn start command with the VITE_WG_PUBLIC_NODE_URL variable, e.g. VITE_WG_PUBLIC_NODE_URL=http://localhost:9991 yarn start. It is recommended to define the variable this way, rather than in .env, as it makes the variable override explicit.

Known Issues

The Treasury Dashboard has a notification banner to proactively communicate any known issues to users. Content is sourced from a Markdown file, and can be edited within the GitHub interface here.

If editing the production content, opt to create a new branch and pull request, so that it can be merged into production.

🗣 Community and Contributions

• Join our Discord and ask how you can get involved with the DAO!

Deploy Your Own Frontend

olympus-frontend's Issues

Add basic tests for button presses & expected behavior (i.e. Approval changes to stake once approval is received)

Add sOHM to your metamask wallet

Definition of Done

• Ohmies can click on a button to view sOHM in their metamask wallet
• Ohmies can view sOHM in their metamask wallet.

Implement all hover states following the Figma spec

Figma for light and dark mode,
https://www.figma.com/file/Yv3MynoOfFbFpd641XTl0z/stake-bond?node-id=220%3A7101

TO DO

Nav bar on left

• on hover there should be an underline stroke and not color change

Nav bar footer

• update icon on hover color for social icons

Header on top

• no highlight color change state on hover. The mouse cursor to thumb change is enough
• [(i) OHM] on should show the popover menu on hover, not select

Stake page

• [Stake OHM] - only text should change opacity.
• On hover the unselected tab for ex "Unstake" should show an underline stroke
• "Stake on Frax" CTA - update default/hover state color application

Bond page

• update hover states for Bond/Claim CTAs
• updated style for "View contract + icon" default + hover state

[v1.3 - backend] Treasury Dashboard: Supply

Definition of done:

• subgraph functionality which returns supply metrics upon request

{
    totalSupply,
    circSupply
}

additional details:

example query:

default bond slippage too high

I was wondering why the default bond slippage is set to 2%. For swaps the industry standard became 0.5%. Would it make sense to set the default bond slippage lower as well?

/cc @OlympusDAO/frontend

Visual style / animation : On hover popover menu "(i) OHM"

Figma,
https://www.figma.com/file/Yv3MynoOfFbFpd641XTl0z/stake-bond?node-id=220%3A7101

• the menu should appear on hover instead of on-click
• update layout of items in the popover menu
• update the shadow spec

ANIMATION

On hover : 200 ms fade-in + move up by 10 pixels to the final position

On mouse-out : 200 ms fade-out + move down by 10 pixels to the default position

Light theme hover/active state nav item border-bottom incorrect

The hover/active state border bottom is not the right color on the light theme for the stake link. Its like darkblue, whilst the others are black.

[v1.3 - backend] Implement Apollo Client for Subgraph queries

Description of Done:

• Apollo Client installed in React app
• subgraph data queries implemented and optimized for application-level data in accordance with v1.3 goals
• existing solution replaced (where applicable) with graph ql requests

Can't Claim and Autostake

When I try to click "claim and austostake" button on my FRAX bond, it errors out with:

[Feature] Code security and quality improvements

We're a lot of different people touching the code, and combined with the exponential growth of Olympus as a project, I think now would be a great time to implement a few measures to prevent technical debt, errors and just keep the code clean. That's why we have Eslint, after all.

As they say, prevention is better than cure.

It's not a big issue right now, and I think I can get it done in a matter of a few hours.

Other than code quality, I receive ≈ 128 warnings when building the front-end, of which the vast majority is simply unused imports (most likely because of removed code without running eslint).

To do

• Fixing warnings in the code (run eslint and supervise it)
• Setup Github action to enforce compliance with the Eslint config

Screenshots

Light theme bonds discounts not readable

On the light theme in the navigation the sub menu on the bonds section the font color is white and not readable. This used to be black or darkish color. This is currently live.

EDIT: The hover is also not functioning properly. Should be a quick css fix or theme.js fix.

Refactor Bond implementation

Is your feature request related to a problem? Please describe.
Adding new bonds require changing 10 files and a lot of knowledge about how the codebase works. There are special conditionals for LP bonds vs regular bonds. See #277 for reference.

Describe the solution you'd like. Include clear acceptance criteria.
It should be a very simple process for when a dev wants to add a new bond type. There should be clear encapsulated & abstracted logic for each bond and bond methods. A new dev can add new Bonds without worrying about the side-effects of their code change.

Is any UX Design input needed?
No

Describe alternatives you've considered
Nope.

Tech Notes/Testing Notes
Added in the additional context.

Out of scope
No specific bond functionality changes, such as claim all and restake, etc.

Additional context
Thinking of something like this.

class Bond {
  let name: string
  let type: string: 
  let lpUrl: string;
  let bondIcon: string; 
  getReserveContract(): () => string;
  getBondContract() () => string;
  // ...  whatever else 
}

// Each bond implements the same methods
class Ohm_Frax extends Bond { ... }

// Have a list of active Bonds
const ACTIVE_BONDS= [...]

Refactor bonds.jsx (related bonds components), bonds.actions.js,

Related Issues:
#146 #158 #286

[v1.2 - Feature] Update TopBar buttons

Description of Done

• Ohm drop down implemented to spec, all links work and open in new tab
• buttons reordered: ohm / disconnect / theme
• hamburger menu button styled to match top bar buttons
• theme toggle icons set to solid white or black (dark / light)

new components:
DropDown.jsx
TopBarBtn.jsx (optional)

Figma

Link legacy staking page to Gitbook guide on how to unstake LP

In v1, Ohmies could stake their ohm/dai LP. We have since deprecated that feature and no longer grant rewards. Rather than support that feature in the UI we have a a GitBook Link:
https://docs.olympusdao.finance/using-the-website/unstaking_lp

Needs design input.

Cloudflare lambda functions for API v1

Description of done:

• lambda functions implemented on CloudFlare to allow olympusdao.finance to fetch Total Ohm staked, current APY, and current treasury balance
• ideal endpoint format: api.olympusdao.finance/ or app.olympusdao.finance/api/

example request:
fetch("https://app.olympusdao.finance/api/v1/treasury.json").then(r => { })

--> response:

data: {
    treasuryBalance: string
    ...
}

Note: throttling may be necessary to minimize request-load on infura node. If possible, request frequency will be limited via cron-job on landing (depends on webflow)

Track pending transactions and display on the UI

Definition of done

• Ohmies can see that their recent transaction(staking/unstaking/etc) is in progress
• Ohmies can see that their recent transaction has completed.
• The UI updates to reflect these state changes.

Update Governance asset in the nav bar.

SVG assets,
https://www.dropbox.com/sh/3b5hscnpb2lb6u6/AACxD8Be-jd_EVvqOUqPAduza?dl=0

[Treasury Dashboard] Data Cards

Replace dune iframe cards with styled data cards using recharts + apollo/subgraph api

AC

• Recharts library installed
• functional chart component and local styles added to /components under /Chart directory
• charts show loading state while fetching data
• hovering an area of the chart shows a styled tooltip with additional data and legend

Charts:

• TVL (area)
• Market Value of Treasury Assets (stacked area)
• Treasury RFV (stacked area)
• Protocol-owned liquidity (area)
• Holders (bar)
• OHM Staked (area)
• APY over time (line)
• Runway (multi-line)

Chart Card Headers:

• title
• current data
• hoverable ? help icon
• clickable expand button (also icon button)

Behaviors:

• hovering the data area shows info tooltip
• hovering ? icon shows help info tooltip
• clicking the expand button shows the selected chart scaled up (use material-ui Zoom transition component) on material-ui Modal / Backdrop
  - [ ] when expanded, that chart card's expand button becomes a collapse button. clicking the collapse button (or anywhere outside the chart modal) collapses it back

Dependencies:

• Recharts
• Apollo

figma

[Fix] OHM/DAI LP staking

Current state:

• LP staking exists ONLY on the vue app with people still staked
• UX is janky and leads people to the old vue app for people who have the old URL: https://olympusdao.finance/#/lpstake

TODO:

• Determine future of OHM/DAI SLP staking.

Definition of done

• Either we have deprecated LP staking entirely w/ appropriate comms on how to unstake through etherscan or have implemented unstaking option in the new UI.

Redeem all bonds functionality

Expected Behavior:

• Ohmies should be able to click a button on the bond page and redeem all their bonds.

Needs:

• UX support for placement of redeem all button.

Helper Contract: https://etherscan.io/address/0xE1e83825613DE12E8F0502Da939523558f0B819E#writeContract

Stake data row - Add current index to stake page

Definition of Done

• Current ohm index component rendered under next rebase in staking interface

---> revision

• replace "buy on sushiswap" in top data row with current ohm index and place right-most column (see design)

Needs:

• design for placement/ux of current index element (done)

note: this code already exists in Sidebar.jsx (only viewable in girth mode) Move to Stake.jsx and remove theme flag

Text overflow

Describe the bug
Text on the stake screen is not shown properly

To Reproduce
Steps to reproduce the behavior:

1. Go to 'https://app.olympusdao.finance/#/stake'
2. Click on 'N/A'
3. Scroll down to 'N/A'
4. See error

Expected behavior
Text box should be made to fit the screen.

Workarounds (if any)
/

Screenshots

Smartphone (please complete the following information):

• Device: iPhone8
• OS: iOS14.6
• Browser Metamask browser
• Version 2.5.0 (750)

Additional context
/

[Feature] Add support for Ledger

We need to support Ledger support outside MetaMask.

Completion Criteria

• You're able to interact with Olympus through Ledger, without doing so through MetaMask.

Additional Information

We're currently using web3modal, and a web3modal provider for Ledger already exist, so it should be straight forward to integrate: @web3modal/ledger-provider.

social buttons do not open in new tab like other links

Hey frens, just a minor suggestion. The links above all open in a new tab. From a UX PoV my expectation would be that the social buttons at the button follow the same behaviour. Though they open in the same page, which creates a little friction. Not sure if this was an intentional decision, though I would suggest to change that.

/cc @OlympusDAO/frontend

[Feature] More info about staking

I want to be able to:

• See how many OHMs I'll be getting in the next rebase. Currently, it only shows rebase percentage.
• See the number denominated in $US amount as well.
• See how many OHMs I gained since last time I staked to determine how many OHMs I've earned since then.

Example:

Next rebase is 1%
I have 50 OHM
It shows me that next rebase is 0.5 OHM / $150 (assuming 1 ohm is 300) and I've earned 10 OHMs since 10 days ago.

Currently, all these numbers/calculations I have to do manually by hand whenever I open the Stake page.

State Management Optimizations

Our state is fragmented and improperly managed across account, app, bond, migrate, and staking.

Currently there are three tiers of state. 1) State that is loaded/changed infrequently (ex: APY) 2) State that is changed on a regular cadence (ex: bond discounts). 3) State that needs to be changed based on user interactions (ex: staked OHM)

Our current state system doesn't account for the frequency of change and adding new sub-states has become increasingly difficult.

Goal:

• Design & Implement a rational state system that allows us to quickly iterate/add new state vars as the project grows.
• Alternatively: suggest a reasonable alternative to Redux (hooks, etc)

Update font colors : light mode only

Figma,
https://www.figma.com/file/Yv3MynoOfFbFpd641XTl0z/stake-bond?node-id=226%3A19384

Stake light mode

• APY, TVL, Current Index
• unselected Stake/Unstake tab
• left-nav "Bond discounts"

Farm Pool

• Asset, APR, TVL, Balance

Please ensure that these updates do not impact the dark mode.

WalletConnect displaying QR code instead of full options

Bug description:
Currently its a bit difficult to connect to your wallet. When you click on the 'Connect Wallet' button the WalletConnect pop up opens, and instead of showing the 4 options to connect, it shows a QR code which is. This issue persists on desktop. Mobile looks good.

To Reproduce
Steps to reproduce the behavior:

1. Go to app.olympusdao.finance
2. Click on Connect Wallet
3. The wallet shows QR code instead of the 4 options that we used to have.

If you were connected, you are still able to interact and see data, but if you're a new ohmie its going to be difficult to interact with the app.

Screenshots

Desktop (please complete the following information):

• OS: OSX MBP 15"
• Browser Chrome

Contract Improvements

Is your feature request related to a problem? Please describe.
Its annoying to update contract addresses/ remember where they are

Describe the solution you'd like
We have ENS names for our contracts. Use them.

Describe alternatives you've considered
Do nothing. Cry everytime you have to change an address and you don't remember if its old or new.

Additional context
Bonus points: make the contracts library a submodule that we can include in this repo.

Bond discounts as links

Description of done

• when i click a bond under the discounts area in the sidebar it should open that bond modal

Max bond % needs to be updated

Describe the bug
The changes to the max bond %'s haven't been updated on the UI

To Reproduce

• Go to the website
• Head to the bond section

Expected behavior
Update the max bond % so it's in line with the recent policy changes

Screenshots

Desktop (please complete the following information):

• DESKTOP

Index metric on Olympus dashboard is incorrect

The Index metric on the Olympus dashboard is showing the incorrect amount. (7.4 as opposed to ~7.2)

Not sure how this is calculated via the Front-end but Sh4dow's dune dashboard is showing the correct amount. Maybe we could use that as the source for the correct indexed amount.

Olympus Dashboard:

Dune Dashboard:

[Treasury Dashboard] Updated Hero Metrics

Hero metrics displayed in single card per design spec

AC:

• Replace multi cards with single data card
• Data fields (L -> R) Market Cap, OHM Price, Circulating Supply, Current index
• fields are evenly spaced and mobile responsive
• data pulled from subgraph api

figma

Alignment - Both selected and unselected nav items should have the icon-text vertical alignment.

You can see that "Bond" and "Dashboard" for example are currently not.

Looks like the line below the selected item is causing that extra spacing for unselected items.

Changing address for Hades doesn't do anything

Describe the bug

To Reproduce
Steps to reproduce the behavior:

1. Go to bond
2. Click cog
3. Change address
4. Proceed to bond
5. Check Etherscan and noticed that the bond was awarded to original address not to the changed address

Expected behavior
Expectation is that bond is awarded to the original address

[v1.2 - infrastructure] Distill CSS into modular components

Definition of Done:

• mobile/narrow/small queries removed from everywhere but app
• bootstrap fully deprecated
• redundant styles removed/globalized
• button and card components implemented to design spec and existing elements replaced accordingly
• Typography defined and implemented uniformly through material ui theme
• Viewport scaling set at 1:1 and elements sized accordingly
• Theme preserved in localStorage or inherited from device settings (fallback: dark)
• Implement material ui Grid to design spec
• Create OhmCard component using material-ui Paper
• global coloring, border radius, and breakpoints, set in custom mui theme and use mui ThemeProvider

Example OhmCard props:
tbd

Requires finalized design spec for main button and card styles

[test:unit] all nav menu and view transitions (i.e. clicking dashboard, brings up the dashboard)

API Ratelimit exceeded infura.io

Describe the bug
API Ratelimit exceeded

To Reproduce
Steps to reproduce the behavior:

1. Go to https://app.olympusdao.finance/#/stake

2. Click on connect wallet

3. Connect Wallet

4. Nothing loads

5. Open console see error
   Failed to load resource: the server responded with a status of 429 ()

6. Go to network tab read server response
   {"jsonrpc":"2.0","id":42,"error":{"code":-32005,"message":"exceeded project rate limit","data":{"rate":{"allowed_rps":3,"backoff_seconds":30,"current_rps":9.633333333333333},"see":"https://infura.io/dashboard"}}}

Implement loading states for data blocks

Definition of done

• placeholder bars/blocks for data areas while loading data or refreshing page
• entering app should display loading screen during initial data fetch
• animate card component display between page changes collapse/slide cards into and out of view on nav events
• Maybe related withh Redux refactor

gear and cross disappear when scrolling down in bond model

This is the view when scrolling up.

This is the view when scrolling down.

I think it would be better UX if core components of navigation would be available at all times.

/cc @OlympusDAO/frontend

[Bug] Provider optimization - When Infura hits limit no blockchain data is available without wallet connect

Background

A fellow ohmie wrote the following:

Is it possible for the app to show all stats (bond discounts, upcoming rebase, etc) without connecting a wallet? Sometimes I just pop in to check and would prefer not unlocking. If not, is there a way to query that data independently?

I follow him. It's generally annoying when dapp interfaces look completely broken until you connect your MetaMask wallet to the site.

Completion Criteria

You should be able to quickly bounce into Olympus' dapp interface and see bond discounts, time until next rebase, current OHM mc etc. etc., even without connecting your MetaMask.

Suggested Solution

We already have Infura integrated, so this is simply a question of checking whether or not the injected provider is connected, and if not, then use the Infura provider (src/hooks/UserProvider.js:58).

Treasury bal -> MV of treasury assets not in sync

Description:
The treasury balance on the website and the MV of treasury assets on the dune dashboard are showing a 8 mill difference as of now (dune was queried 2 hours ago).
I'm aware that the AAVE deposit and xSushi may not be showing but there's still a decent chunk that isn't accounted for.

To Reproduce
Steps to reproduce the behavior:

1. Go to both Sh4dow's dune dashboard and the Olympus website dashboard.

Expected behavior
Identify which one is showing the incorrect amount and amend.

Screenshots

Currently an 8mill difference

Add integration check on github to run tests to validate PR before Merges

Handle web3 providers properly with graceful fallbacks

Is your feature request related to a problem? Please describe.
A few problems:

• Users are shown NaN when the mainnet infura provider gets rate limited.
• The app doesn't gracefully handle injected providers vs read-only providers.

Describe the solution you'd like

• We should have reliable mainnet providers (alchemy, pokt, nodesmith, infura, etherscan, etc)
• Providers should be accessible through 1 helper utility which handles the injected vs mainnet providers. It should handle the priority of providers & have reasonable defaults: 1) Injected 2) infura 3) etherscan 4) ???
  • Ribbon finance does this by using a global web3Context and react hooks to access it here

Describe alternatives you've considered

• Pass around a provider variable to all sub components/views (sounds bad.)

Additional context

• Cleaner provider usage will help us build cleaner contract interactions.

Related Issues:
#262

New task:

• update context object logic to automatically update provider on network change

Typescript refactor for olympus-frontend

Intro
I believe that refactoring the olympus-frontend to utilize Typescript will enable all current and future developers to have a nicer development experience and become much more productive in the long run as having types has multiple benefits: consistent styling and clear and explicit intent.

Coding on a team includes the dual task of expressing to the computer what you want it to do and communicating effectively to your teammates (and future self) what your intent is. This sort of "common language" is essential especially when trying to coordinate development efforts in such a decentralized manner, especially at scale. Below I outline the goals of this proposal, the outcomes I hope to achieve from it, the needs of the proposal, alternatives, a rough timeline and additional information for reference.

Goals

• Discuss on a set of Typescript standards we will use for the refactor
• Refactor the olympus-frontend to utilize Typescript
• Ensure there are no breaking changes through rigorous testing, especially if we're planning on doing a project-wide refactor

Outcomes

• Improve the developer experience
• Some cleanup of unused props, etc.
• Allow developers to work more efficiently allowing productivity gains across all developers once this change is implemented:

1. TS will result in more readable code, intent will be explicit for both other developers and your future self.
2. Productivity gains for developers: there is an initial cost (of time) where sometimes the first developer working on something may not know the type and will have to discover it themselves, but this will allow all future developers to be certain of what the datatype is beforehand and the time taken to test this adds up when done multiple times across multiple developers (saves dev time for more pressing tasks)
3. Autocomplete for contract functions w/ Typechain as well as knowing exactly what certain things return and take in as parameters.
4. Easier debugging/Fewer bugs - Typescript is pessimistic and won't compile if something is off, for example if you haven't handled a case where something might be undefined: https://github.com/0xdavinchee/olympus-frontend/commit/18bf6df0f2cbfad023507059d4aa88e16456f87a#diff-f3a239449bbebaac8df3a75ce26114955a8ef7a2b7f768ce0a83bdae7e8972b4L102-R136
5. Future refactors - similar to the point above, if we want to make any project-wide refactors in the future, having a TS project will enable developers to do so with full confidence in knowing that any misspelled variables or other issues would be caught immediately (code won't compile).

Needs

• Developers
• Lots of testing (can never be too safe)

Alternatives

• I'm not aware of any TS alternatives in terms of type safety/checking and I believe given the support/industry standards around TS in the development community that this is the best solution.

Timeline
I believe that this refactor is fairly straightforwards, honestly the most difficult part with TypeScript is often setting up the project to allow TypeScript files and the project didn't require too many changes to get TypeScript fully working. However, there is always the possibility we may encounter more problems as development starts. In addition, integrating TypeScript should not break anything as long as everything is compiling correctly. The most time consuming part would be the testing.

• Optimistic: 1-2 weeks
• Realistic: 3 weeks
• Pessimistic: 1 month

Caveats

• There may sometimes be a small upfront time cost for the initial developer implementing things when the type is unknown
• There will be packages which don't have types and this will require us to declare the module in a .d.ts file to override Typescript complaining: declare module "@package/no-types-package";
• Certain things require complex understanding of Typescript (for example in constants.js, the addresses variable has a pretty complicated type:

export type Nested = { [key: string]: string };

interface IAddresses {
  [key: number]: { [key: string]: Nested | string };
}

I have provided a solution, but it's not the cleanest way to do it. This could be fixed by fixing up the way this object is defined or figuring out the way of defining this type in Typescript.

Additional Info
I've gone ahead and added some stuff to the project config so that it works and made changes to a few files just to illustrate the power of Typescript:

• https://github.com/0xdavinchee/olympus-frontend
• Breakdown of the changes: https://discord.com/channels/838651642190495804/838654073464946758/866310332900442122

[FIX] Approve OHM button should update to Stake OHM when done

Describe the bug
When users need to approve $OHM first and then stake it.
The button "approve OHM" doesn't update to "stake OHM" when the approved tx is successful.
The user needs to refresh manually the page to be able to stake it.

To Reproduce
Steps to reproduce the behavior:

1. Go to /stake with a wallet that hasn't approved OHM yet
2. Click on Approve OHM -> tx on Metamask is a success
3. The button still showing you Approve OHM

Expected behavior
The call to action Approve OHM should update to Stake OHM when the approved tx is a success.

Desktop (please complete the following information):

• OS: PopOs (ubuntu)
• Browser Brave (Chrome)
• Version Version 1.27.69 Chromium: 91.0.4472.106 (Official Build) beta (64-bit)

pressing ESC does not close bonding modal

An issue I personally have is that if I press ESC I intuitively expect the bonding modal to close. Though we do not have key bindings setup it appears. That may be a feature request.

/cc @OlympusDAO/frontend

"Switch network" alert if user is on the wrong network

Is your feature request related to a problem? Please describe.

When users visit olympusdao.finance, connects their wallet but are connected to a wrong network, the UI bugs out and nothing is showing.

Describe the solution you'd like

When a user connects his wallet, we should check if he's on the correct network. If not, prompt a pop up telling the user he needs to connect to Ethereum mainnet, and allow him to click a button in the pop up saying "Switch Network".

Clicking the button should trigger the network change in the user's wallet provider.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context

[v1.2] Move wallet address to sidebar

Description of done:

• wallet address button removed from TopBar
• Wallet address displayed as clickable link beneath olympus brand header (same link as original button, wallet etherscan)

Test Suite

Current state:

• Dev's current manually deploy/QA changes through branches.
• See our experience through v1.1 deploys

TODO

• #227
• #225
• #226
• ???

Definition of Done

• We have Happy path testing.
• Devs have increased confidence that their UI changes are not breaking.
• We can more easily make foundational changes.