paritytech / paritytech/web3-storage

Retrieve completed challenges gracefully for UI

Open
#238 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
13
Forks
3
Avg merge
2d 2h
Merged PRs (30d)
33

Description

Currently the challenges view of the provider UI uses a hack to render the completed ones by storing the ones that were seen by the page in its localStorage and consulting it on reloads. However, using the front end this way shifts responsibility and hides that the chain is the actual source of truth, so it's better to come up with an alternative way of doing that (and avoiding the clunk with things crashing upon schema changes etc).

I'd rather steer away from having schema hand encoded via some rehydration. Or if we really want to land it, we should probably enforce the schema with versions via something like zod so there's less chance to experience drift when anything challenge-related moves sideways and this snippet is forgotten.

And while we're on this, let's talk about the role of local storage in UI overall: if I remember correctly, it was introduced to keep challenges that have already expired visible to the provider in UI. But it should not become a source of truth that we rely on, only a cache in the best case. And what would make most sense is probably reconstructing the resolved challenges via querying some block range on chain for respective events, or just straight out abandoning this functionality and only leaving unresolved ones visible as it's ultimately the way it's meant to be.

Originally posted by @ilchu in https://github.com/paritytech/web3-storage/pull/194#pullrequestreview-4505275989

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the provider UI's challenges view and trace how completed challenges are stored in and restored from localStorage. Review the surrounding challenge data flow and determine whether resolved challenges should be reconstructed from chain events or omitted; the issue is done only after a source-of-truth decision and an agreed implementation are established.

Written by the indexing model from the issue text.

Assessment

Domain
frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.