proveuswrong / webapp-tp Goto Github PK

listArticles component calls setFetchingArticlesContents(false); inside useEffect but since it's not synchronous, false value comes late so this statement causes the FOUC.

We could make setFetchingArticlesContents(false); synchronous to solve this issue, somehow. This article might help.

use newly implemented function withdrawFeesAndRewardsForAllRoundsAndAllRulings

https://github.com/proveuswrong/webapp-news/blob/9bb0fadb695dd741d82d46920302abbc8503e426/src/data/ethereumProvider.jsx#L60

As in the above statement, we are long-polling the block number from Graph to decide whether the content is old and needs refreshing, like in the statement below:

https://github.com/proveuswrong/webapp-news/blob/9bb0fadb695dd741d82d46920302abbc8503e426/src/routes/browse/index.jsx#L24

This does not make sense. Because before we make an HTTP request to Graph to fetch new data, we ask if there is new data, and to be able to ask, we make an HTTP request, which eliminates the cause (of minimizing HTTP requests). So why was this done? Because initially, we were listening to block numbers from a Web3 provider, but then we realized if none was provided, the web app won't be able to work properly. It seems we switched to pulling block data from Graph to fix this issue.

Alternatives for a solution:

• Assume a Web3 connection will be provided by the user. I don't like this.
• Provide a Web3 connection, like Infura or Alchemy, through env vars to guarantee the connection.
• Instead of long-polling for block number, long poll for actual content to eliminate unnecessary HTTP requests.
• Should each query have its own last-fetched time? Or should we keep a global constant? If each component keeps its own, then which one will SyncStatus show?

The last option seems the best. However, refactoring is not easy. Things to consider:

• SyncStatus component relies on block numbers from Graph metadata.
• Many components rely on block numbers from Graph metadata via their useEffect hooks. Their dependency array contains this block number variable, so when it changes, a new query is made to the Graph endpoint.

Ideally, we should do an initial fetch and save this timestamp. And keep track of the time delta between now and the last fetch to trigger a new fetch.

Fixing this issue will reduce the number of queries (to Subgraph) to half. This is not important now since we are on testnet, but will be important when we launch on Mainnet since we will be paying for each query.

Functions which provide access to data, such as getAllMetaEvidences, which acts as an interface for components, should not take chainID or contractInstances as an argument. The data layer already provides the Ethereum context, so it should work without pointing to the context again.

This page should display user-related data. At this point, displaying all articles reported by the account address is enough.

The modal below should be rendered when the Double Bounty button is clicked ( Article route page)

Don't horizontally pad list items in the narrow layout where there is no frame around items. When there is no frame, horizontal padding does not help items to look good, and also in narrow layout page sides look too thick.

Markdown, HTML, and maybe both.

The Header component currently includes a combination of JavaScript and CSS code to enable simple animations, but this approach is not the most efficient.

To improve the quality of the code and promote simplicity and readability, refactoring is needed.
Note: consider separating nav and header

claim is actually and article, for example. There are many instances of these inappropriate namings.

Sometimes it displays an unsupported network, but it's not.

The value of Arbitrator field within the Arbitration Details section should be a link to the Court Page. This page should include all relevant information about the court

• name
• id
• policy
• times per period

put on hold

• arbitration fee
• parent courts
• active jurors
• the number of disputes in the last month

It happens after clicking. Find why and fix it.

This becomes a problem when there is no web3 provider because then we don't know the latest block number.

Perhaps we can pull from Graph.

Hide navigation items under the burger menu when the screen size reaches 760px. Clicking on the burger menu should render the overlay menu.
Reference: https://proveuswrong.io/

Mockups

• Evidence period
• Voting period
• Appeal period

See visual design here.

Implementation

• Period tracking
• Evidence submission
• #47
• Fetch Appeal data from subgraph
• Fetch Voting data from subgraph
• Pass arbitrator period
• Execute arbitrator ruling
• Draw jury

If no provider, network dropdown should not trigger provider effects. Will require some refactoring since I implemented it with some wrong assumptions.

• Mark the Execution item of Timeline as checked when the ruling is executed
• Display an informative message in the rewards field when a connected account has not contributed

• Contribution - character encoding issue
• Rewards Withdrawal - ignore
• Evidence - ipfs uri (must be fetched data)
• ArticleWithdrawal -> Article Unpublished (?) & last calculated score (?)
• TimelockStarted - unformatted UNIX timestamp

Pages

• Browse
• Article
  • #244
  • #245
  • #248
• Report
• Account

Modals

• IncreaseBounty
• #242
• Submit Evidence

Or at least present a toast message with a link.

• #97
• #98
• #101
• #102
• #103
• #118
• #105
• #111
• add text-decoration: underline to Arbitrator field in Arbitration Details section

The value of blocks in the tooltip of the bounty has become undefined, most likely due to a variable name issue resulting from recent subgraph updates.

It is deprecated in favor of _colorsNew.scss. The new file has colors in HSLA instead of RGBA.

In DisputeTimeline component, useCountdown hook keeps rerendering even if there is no time left. Probably a guard check should be in place to prevent unnecessary rerenders.

We have the design in Figma but it seems we did not apply it yet.

Silently waiting for confirmation is not a good user experience.

I'm no longer the sole programmer in this project, so the need for a more sophisticated workflow has emerged. Implementing a workflow like this will let us do more testing before jumping to the production environment.

Implementing such workflow requires preventing pushes to the production branch except for whitelisted branches. For example, we should only let pushes to production from staging or hotfix branches. AFAIK, Github does not have such a branch protection rule option. The other option to implement this restriction is doing it directly within Git, using hooks.

Example scenario to implement: Prevent pushes to main, except from dev or hotfix/* (note that * is a RegEx wildcard here).

Help wanted. Up for grabs.

Add a section in Arbitration Details component that will list all submitted evidences related to the current dispute below the timeline component

Refactor out claim component from claim route. Implement handling in the route component.

check this
https://reactrouter.com/en/main/hooks/use-matches

https://reactrouter.com/en/main/routers/picking-a-router

• fundAppeal