Conversation
|
This one is ready @lidel :D |
There was a problem hiding this comment.
Finally, got to spend some time with this :)
Works really good, want to include it in go-ipfs 0.11 if possible.
Before we merge this, need to add some e2e tests tomorrow:
- add key and confirm pet name is added to the table
- publish to the key from files
- confirm link on the settings screen got updated
- remove key and confirm it's gone from the table
- publish to the key from files
For now, pushed small changes which tweak some modals a bit:
There was a problem hiding this comment.
Added E2E tests and cleaned them up a bit, should be pretty robust now that we use playwright.
@hacdias I think we have UX gap around publishing, which blocks this from being shipped.
Need some sort of confirmation that publishing was successful.
Visual feedback on IPN Publish
Right now I click Publish and nothing happens.
We need three states:
- "Publishing in progress"
- "Publishing successful" / "Publishing failed"
A nice flow would be if clicking on "Publish" displayed spinner until ipfs.name.publish returns result (success/error), and then:
- if error, show error inside of the modal.
- if success, show "Succes, published at {keyid}" and below the same UI we have on "Share" modal, where user can copy a shareable link to
/ipns/address at a public gateway.
@hacdias will you have bandwidth to add this?
I think it is better to wait and polish the experience, so I'm descoping this from go-ipfs 0.11, so there is no rush.
|
@lidel I'll work on it. |
|
@lidel it's still missing the actual spinner. Could you just validate if the workflow is good? |
|
@hacdias yes, the user flow ending with "sharing screen" and "Copy" action is perfect 👌 Figuring out an engaging spinner will be tricky – some thoughts:
ps. fysa pushed two changes: |
I will do this. Seems to be the easiest. Using a spinner would probably not be the greatest idea idea, indeed, as it does not give feedback. |
|
@lidel I added a progress bar that is initially 60 seconds. After each publishing, we average the current expected time with the new time it take. I think that this way, it should improve and have better expectations over time. |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
@hacdias really nice!
- I adjusted the rolling average to overshoot rather than undershoot (apps fake progress and usually finish around 75% to give that "snappy feeling", we guess based on past times, which is better, but still should overshoot to avoid being stuck at 100%) + added brief explainer what is happening, so the wait is a bit more justified:
- Pretty close to being mergable. I'm marking this as blocked on go-ipfs roadmap:
- We need to figure out if it is ok to ship the GUI for IPNS before we have things like ipfs/kubo#8591 and ipfs/kubo#8586 in go-ipfs, or are those worth waiting for. Will pick this up and make the decision in January.
| useEffect(() => { | ||
| if (!start) return | ||
|
|
||
| const interval = setInterval(() => { |
There was a problem hiding this comment.
💭 nit: I wonder if we could remove setInterval here and use css animations instead somehow? (would look less choppy, we could also make it more engaging by making it non-linear).
I'm thinking setting progress to 100% and using animation: progressBar ${expectedPublishTime}s ease-in-out for customizing the progress animation instead.
Just an idea, feel free to ignore.
|
@lidel I added an option that will make |
dabaee3 to
7ddf870
Compare
lidel
left a comment
There was a problem hiding this comment.
@hacdias I don't believe ipfs/kubo#8591 or ipfs/kubo#8586 will happen this quarter, let's not wait anymore. I think it is ok for us to ship it because IPNS publishing should be in IPFS Desktop, and unlike the upstream kubo (go-ipfs), IPFS Desktop has IPNS over pubsub enabled by default, so performance will be acceptable.
Mind resolving conflicts in this PR and pinging me when ready? 🙏
|
@juliaxbow this is a great candidate for your review and help! |
50f9c8a to
857bdf5
Compare
857bdf5 to
7ddf870
Compare
|
I tried a different of rebasing and I guess I messed up this PR. Sorry for that and won't happen again. The branch is fine, but this PR got closed and I can't re-open it. Continue on #1973. |





Closes #1482.
A bunch of screenshots
The context menu is a bit unaligned. The same happens with the Pinning Services context menu. The target reference seems correctly set so I'm not sure why's this miscalculation happening.