Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: connect Expeditions modal to the expeditions api #1433

Open
wants to merge 34 commits into
base: develop
Choose a base branch
from

Conversation

adamazad
Copy link
Contributor

@adamazad adamazad commented Sep 6, 2022

Summary

Connects the Expeditions modal to the API hosted at https://api.swapr.site/v1.0/documentation

To Test

Testing this feature requires on-chain transactions. In order to claim weekly fragments. User has to deposit or stake $50 or more worth of liquidity on any of the three chains Swapr core supports: Mainnet, Arbitrum and Gnosis Chain.

@adamazad adamazad linked an issue Sep 6, 2022 that may be closed by this pull request
@netlify
Copy link

netlify bot commented Sep 6, 2022

Deploy Preview for swapr failed.

Name Link
🔨 Latest commit fd10318
🔍 Latest deploy log https://app.netlify.com/sites/swapr/deploys/639fac26408e72000909c45f

GENERATE_SOURCEMAP=false
REACT_APP_SWAPR_API_BASE_URL=http://localhost:4000
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might mess up Netlify deployment tho.

@KeenanLukeOM
Copy link

Doing some testing, here are some findings and suggested changes. All of the below were tested on Gnosis Chain:

  1. I deposited roughly $200 of GNO/DXD liquidity, which didn't cause the "Provide liquidity" task to complete. Upon staking that balance, the "Stake liquidity" task was completed. Currently unsure what the cause may have been.

image

Depositing liq: https://gnosisscan.io/tx/0x84a9483570a1a028be907252242dad386e80c532563a06acbf64ef47853a05a4
Staking liq in campaign: https://gnosisscan.io/tx/0x11e58a7bf5a4cc1ccc6d083b73f15fdb97fd3f9e307719b113fea63dce5ddc51

  1. Flow for completing a task is exceptional. Looks great. Any way we can implicate a timer until the next weekly tasks unlock? EG: CLAIMED -- NEW TASK IN 2d 4h

image

  1. I've adjusted the design for the switch between Action and Rewards to keep the current fragment balance sticky. This can be found in the design working doc, here: https://www.figma.com/file/R1ibNl3sv1KoQ2BTO7qDBC/Keenan-Working-Sheet?node-id=1672%3A5180

image

  1. Could we add a dynamic element to the Expeditions icon for when a task (or reward?) is claimable? I interpret this as a glow that fades in and out over a 2-second loop, but leave the decision up to @0xVenky.

image

Besides the above, functionally this seems sound. Great stuff! The next step is Rewards and how to test the claiming process of some dummy NFT's I'd reckon. Speak on a call soon!

@0xVance
Copy link
Contributor

0xVance commented Sep 15, 2022

@KeenanLukeOM

  1. Flow for completing a task is exceptional. Looks great. Any way we can implicate a timer until the next weekly tasks unlock? EG: CLAIMED -- NEW TASK IN 2d 4h

So for each completed task user would see a timer on the button showing the same countdown. Maybe instead, we can show the number of current week + single timer until week ends? For example it would be below 'Learn more' sign It would also suggest when new tasks will be available.

image

  1. Could we add a dynamic element to the Expeditions icon for when a task (or reward?) is claimable? I interpret this as a glow that fades in and out over a 2-second loop, but leave the decision up to @0xVenky.

Something like this?

Screencast.from.15-09-22.01.32.40.webm

@KeenanLukeOM
Copy link

@0xVance

So for each completed task user would see a timer on the button showing the same countdown. Maybe instead, we can show the number of current week + single timer until week ends? For example it would be below 'Learn more' sign It would also suggest when new tasks will be available.

My interpretation is that showing the time until the specific action is available again scales better, since we have been discussing a daily campaign, event-specific campaigns, etc. I defer to you folks on the team, but I would personally be for a way of indicating the time until the next claim directly in or around that task.

Something like this?

This is exactly what I had envisioned! Any thoughts from your end? Chatted with @zamli about how this could be visualized so defer a decision to him.

@0xVance
Copy link
Contributor

0xVance commented Sep 16, 2022

My interpretation is that showing the time until the specific action is available again scales better, since we have been discussing a daily campaign, event-specific campaigns, etc. I defer to you folks on the team, but I would personally be for a way of indicating the time until the next claim directly in or around that task.

Fair enough, I had only weekly challenges in mind and forgot about daily and other possible tasks.

This is exactly what I had envisioned! Any thoughts from your end? Chatted with @zamli about how this could be visualized so defer a decision to him.

Personally I love it, it could stay like this all the time 😎

@github-actions github-actions bot temporarily deployed to feature-1368-connect-expeditions-modal-to-the-expeditions-api September 25, 2022 21:59 Destroyed
@github-actions github-actions bot temporarily deployed to feature-1368-connect-expeditions-modal-to-the-expeditions-api October 1, 2022 14:52 Destroyed
@github-actions github-actions bot temporarily deployed to feature-1368-connect-expeditions-modal-to-the-expeditions-api November 8, 2022 00:32 Destroyed
Copy link
Collaborator

@berteotti berteotti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great, good work Adam. Just left some comments

@@ -16,11 +16,14 @@
"cypress:run": "cross-env cypress run -r mochawesome -s 'tests/cypress/integration/smoke/*'",
"integration-test": "start-server-and-test 'serve build -l 3000' http://localhost:3000 'cypress run'",
"synpress:ct": "cross-env start-server-and-test 'react-app-rewired start' http-get://localhost:3000 'yarn synpress:run $TEST_PARAMS'",
"codegen": "yarn codegen:socket && yarn codegen:expeditions && yarn codegen:graphql",
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks organized

Comment on lines +15 to +17
export function capitalize(string: string) {
return string[0].toUpperCase() + string.slice(1)
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can be done with CSS only. text-transform: capitalize does the trick

<Row>
<TYPE.White fontSize="12px" lineHeight="150%" textAlign={'center'}>
Expeditions are missions you can complete on Swapr to earn “Star Fragments”. These can be redeemed for
special NFT's and various other rewards. <StyledExternalLink href="#">Learn More</StyledExternalLink>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't forget to set this link.

Comment on lines 16 to 45
const claim = async () => {
if (isClaimed || isClaiming) {
return
}

setIsClaiming(true)
try {
const address = await provider.getSigner().getAddress()
const signature = await provider.getSigner().signMessage(ClaimRequestTypeEnum.DailyVisit)
await ExpeditionsAPI.postExpeditionsClaim({
body: {
address,
signature,
type: ClaimRequestTypeEnum.DailyVisit,
},
})

const { claimedFragments, tasks } = await ExpeditionsAPI.getExpeditionsProgress({
address,
})

// Update local state
setTasks(tasks)
setClaimedFragments(claimedFragments)
} catch (error) {
console.error(error)
} finally {
setIsClaiming(false)
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This logic seems very similar in all 3 components. Maybe we can set a hook with this logic that receives a different ClaimRequestTypeEnum type

}}
className={activeTab === ExpeditionsTabs.REWARDS ? 'active' : ''}
>
{<Badge badgeTheme={claimableRewards ? 'green' : 'orange'}>{claimableRewards}</Badge>}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are curly braces required here?

@@ -0,0 +1 @@
export {}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should export something here

if (isClaiming) {
buttonText = 'Claiming...'
} else if (isClaimed) {
buttonText = 'Claimed'
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we present the claimed fragments too?

)

export const StatusTag = ({ status }: { status: StatusTags }) => {
if (status === 'loading') {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if is an overkill but maybe "loading" should be a constant.

const LOADING = "loading"

Suggested change
if (status === 'loading') {
if (status === LOADING) {

duration?: 'Weekly' | 'Daily'
title: string
description: string
buttonText: React.ReactNode
Copy link
Collaborator

@Diogomartf Diogomartf Nov 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's odd that buttonText is a ReactNode, shouldn't it be a string?

import { ContentWrapper, ExpeditionsLogo } from './ExpeditionsModal.styled'
import { ExpeditionsRewards } from './ExpeditionsRewards'
import { ExpeditionsTasks } from './ExpeditionsTasks'
export interface ExpeditionsModalProps {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would add a new line here.

Suggested change
export interface ExpeditionsModalProps {
export interface ExpeditionsModalProps {

const rewards: RewardCardProps[] = ['common', 'uncommon', 'rare', 'epic', 'legendary', 'mythic'].map(
(rarity, index) => ({
buttonText: index === 0 ? 'Expired' : index === 1 ? 'Claimed' : 'Claim',
description: `Lorem ipsum dolor sit amet, consectetur adipiscing elit. Duis tempor, ante nec consectetur vulputate, eros nisi placerat neque, ut volutpat diam tellus ut sem.`,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can't forget to update this description.

Comment on lines 19 to 27
export const ExpeditionsRewards = () => {
return (
<>
{rewards.map((props, index) => (
<RewardCard key={index} {...props} />
))}
</>
)
}
Copy link
Collaborator

@Diogomartf Diogomartf Nov 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In an arrow function we can remove the explicit return.
It's just a suggestion but I think it is cleaner.

Suggested change
export const ExpeditionsRewards = () => {
return (
<>
{rewards.map((props, index) => (
<RewardCard key={index} {...props} />
))}
</>
)
}
export const ExpeditionsRewards = () =>
<>
{rewards.map((props, index) => (
<RewardCard key={index} {...props} />
))}
</>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Connect Expeditions modal to the Expeditions API
5 participants