guildxyz / agora-frontend Goto Github PK

Addresses and ABI can be found in discord

When we click on the wrong network button, it just triggers a MetaMask prompt to switch to the requested chain.
We should have a modal here:

• In the explorer, we should give the option to connect to any supported chain, maybe display the available communities on them
• On the community page, we should give the option to switch to a chain, the token is available on, maybe display the token balances on the on these networks as well. Those chains that are supported by the app, but the token is not available on, should be disabled with a tooltip

Thought this would make this component more readable, but not sure, we'll see.

Implement the getInviteLink of the joinModalMachine inside useJoinModalMachine.ts

Currently, we are asking the user to stake the whole required amount at every level, but the user should only stake the difference between the required amount and what he already staked.
For example:

• Someone has access to level 2, which he staked 10 X for
• Level 3 has a staking amount requirement of 50 X
• The user should only stake 40 X to get access to level 3, not 50

We already have the component, but it's just a plain link now. To make it look like as it's designed in Figma, we should move the InfoTag component to common and reuse that. Also we should use the LinkOverlay component from Chakra for accessability

The error thrown in the approve function in useTokenAllowance.ts should be converted into an Error object, something like this:

const approve = async () => {
  try {
    const tx = await tokenContract.approve(contractAddress, MAX_VALUE)
    return tx
  } catch (approveError) {
    const error = Error(approveError.message)
    error.name = approveError.code
    throw error
  }
}

This converting logic is also done in usePersonalSign.ts, maybe we should extract it as a top-level utility.

Provide a real processError function in StakingModal.tsx.

On some elements, when I move the focus away from them (with either tab or click), the default 1px black browser outline flashes for a second. This occours on every focusable element in the Account / WalletSelector Modal, but doesn't on the buttons in the community page. I guess the focus-visible dependency causes this (which provides a js polyfill for browsers not supporting css focus-visible), it should be further investigated.

Prop drilling is already getting out of hand, so we should just provide the whole object to the child elements with context. It won't ever change so we don't have to worry about unneccessary rerenders.

The SignError and ConnectionError only differ in the logic that sets the states depending on the error object.
Implement a common Error component that takes an error object and a function that returns the necessary data for the states:
{ title: "", description: "" }
This is a high-priority issue since we will need this in the staking modals.

New account button - design in Figma.

Right now we have a hardcoded 2 sec for every chain, which we've burnt in for Polygon. We should make it dependent on the current chain, dynamic when there's an api for it (implemented in #49, only mainnet now afaik) and hardcoded when there isn't

Right now all communities are in the "All communities" section. We should implement so the applicable ones go to the "Your communities" and "Communities you have access to" sections

Right now the conditional UI rendering for the token allowance machine is duplicated in StakingModal and UnstakingModal. We should extract it to a component

I believe some things would be more readable and simple with this.
I don't think there are as many levels for this to cause performance issues.

Right now the Tooltip children are just wrapped in a Box in the Staked and Platforms components. This is noisy, and not accessible since these divs aren't keyboard focusable, so the tooltips won't be shown if the user navigates using the keyboard. We should use the Tooltip component's shouldWrapChildren prop, but it has a problem right now too: it stays focusable even if the Tooltip is disabled, so it breaks our keyboard navigation flow when the buttons are enabled. I'll open an issue and possibly a PR at Chakra, then we should switch to shouldWrapChildren if it gets merged.

State management of the modal handling the join process (opened with join discord/telegram buttons)

Implement the admin page, as designed in Figma. The community theme picker will be a "coming soon" feature for now.

We should keep the local hardcoded setup too for testing and development, I think we should create a Next api endpoint for it so we can just easily switch between localhost and api.agora.space

Differences to the Figma prototype:

• It should be shown statically for levels that the user has access to, not just on hover
• At levels the user don't have access to yet (while hovering over them, or having their staking modal open), it's color should be 1 or 2 swatches lighter

Refactor the useBalance component, so it doesn't return the whole SWR result, just the balance, to avoid destructuring a "data" key when we use it.

We should investigate why and fix it

Implement a dummy leavePlatform() for now, that raises an error "Not implemented", this should be displayed with the common/Error component

I analyzed the Agora app too in terms of SEO/performance/accessibility, and made a list of the recommended improvements:

SEO

• We should add meta description to the pages
• Add title tag on the community page
• ❗ It seems like the community page isn't server side rendered, I think it would be a good idea to render the most important data (like community name, description, etc.) that way - we could also use this data to populate meta tags on this page!

Note: I see that we're fetching data in getStaticProps, so I'm not sure why the page isn't rendered server side. Any ideas? 🤔

Performance

• We should properly size images in the app too - we can set an explicit width & height to them, and we could also use properly scaled images (if possible). Since we're loading a lot of images on the front page, this might improve the initial load speed a lot.
• Maybe we should add lazy loading to the community logo images (on the front page, where we list the communities)? Note: it isn't necessary now, since we're displaying images in a smaller scale. We could use the Next.js Image component, but that would generate optimized images on Vercel, and wouldn't fetch images every time from the AWS S3 servers
• Longer cache lifetime can also improve performance, so we could use longer cache expiration time where possible (e.g. for images which won't change frequently) - link Note: right now most of the images are fetched from coingecko, so we can't really modify this...

Accessibility

• Headings aren't in the right order, we don't have h3 tag on the front page, but we have h2 and h4 tags.
• We should add alt attribute to the community logo on the community page

Best practices

• We should add rel="noopener" or rel="noreferrer" to external links (e.g. in the dropdown menu below the logo)

Optional Note: will be added in a separate PR

• Add Google Analytics & Microsoft Clarity or maybe Plausible (?) to the site, so we can analyze how users interact with our website

Implement the unstaking flow as it's designed in Figma

Implement the isMember function inside PlatformButton.tsx

It's not possible yet unfortunately (only on non-default chains), but adding it here so we can track the issue and implement it as soon as we can. It'll provide a much better UX than switching manually.

Right now it's hardcoded as a placeholder. Implement to get it dynamically

Modals in the community page are using the default primary color right now, because they're mounted outside the element the css vars are overriden in. We should use portalProps to mount them inside so they'll follow the community's color scheme too.

Setup a test environment where we can deploy specific smart contracts with Metamask from browser.
The platform should be optional. (Ethereum, BSC, xDAI, Polygon etc.)

Implement dark mode for the current default theme as designed in Figma. It should be automatic by default but manually toggleable (we'll have to find a place for the toggle button)

Implement a useMembersCount hook that fetches the member counts from the API using SWR.
Endpoint: GET /community/getMemberCount/:communityId

We need a similar color palette for every community to what we have in our design system for general colors. A challenge is that the community color could be anything, we don't know what swatch it'll be in the generated palette. https://grayscale.design/app does something like we need, but as I've seen it's not open source so we can't dig into it. https://tailwind.simeongriggs.dev/ is, but it can't treat the dynamic lightness/intensity, it always treats the color it gets as swatch 500. A bigger research is needed to see what's out there. Chakra has some palette generator recommendations too here

If we find a solution, the community context provider should render a div around it's children, and override the --chakra-colors-primary-[lightness] css properties in it, so we can just use e.g. colorScheme="primary" inside and it'll follow the community's color scheme. For the CommunityCard component on the all communities page, we will just wrap it with the provider too (it's needed to display the token symbol according to the selected chain too - that's the other thing the provider currently does over just providing the bare community data it gets).

Later the open levels will not need a wallet to connect to platforms, but for now, it looks weird to display "you have access" while the join buttons are disabled

Refactor the AccessIndicator relevant logic in Level into a state machine. This will reduce/eliminate the need for conditional checks in useEffects and simplify everything. You should also add a loading state, which the machine won't get into yet but we'll be able to wire it up later (and the UI will be ready for it)

There're no designs for mobile view. Feel free to experiment and implement the UI for mobile and every possible screen size as you think it fits best. I think this issue can sum the progress of everything we have currently becoming responsive, you should just open different PRs for different parts of the app, that's where the relevant communication will go.

Maybe the state management of the modals would be better with useStateMachine
Investigate if that is what we need here, and if it looks good, refactor the platform modals to use it

As we've discussed on Discord

The { code, message } type that we call SignError should be MetaMaskError, and I think we should separate a processing function, that handles all the possible errors, since we already need this in the joining, staking, and unstaking process.
This function could be directly used in the staking and unstaking process, so we could delete processStakingError and processUnstakingError, and in processJoinError, we could do just this:

if ("code" in error) { // We could also make this check a little nicer if we use a class for MetaMaskError
  return processMetaMaskError(error)
}

We also want to support multiple wallets in the future, it could also make that change easier.
If we do need this change, it should be implemented after #40 is merged.