PE-9211: The version list becomes a control the recipient can use - #2189
Draft
vilenarios wants to merge 13 commits into
Draft
PE-9211: The version list becomes a control the recipient can use#2189vilenarios wants to merge 13 commits into
vilenarios wants to merge 13 commits into
Conversation
added 2 commits
August 19, 2026 18:12
The version list was read-only - date, size, and a marker on the one the link shared - while the only way to change what you downloaded was the banner's two shortcuts. A list you can expand but not act on is a strange thing to have. `showRevision` is the general case behind those shortcuts, so a recipient can pick any version the file has. The banner stays honest afterwards because "a newer version exists" is re-derived from where the selection landed: on the newest revision there is nothing left to offer, on any older one there is. The link's own revision is still remembered, so the way back stays open. Opening the list no longer waits on anything. The version the link named is already in hand - it is what the page is showing - so it renders from the first frame and the rest of the history fills in around it. A failed lookup then costs the list and nothing else: the row stays, the file stays downloadable, and the page can still name what it is offering. That is the state a rate-limited connection actually lands in.
One row per version, a radio marking what Download will fetch, and a chip for either the newest version or the one the link named. Choosing a row moves the target, guarded by the same rule the banner's actions already follow: nothing moves while bytes are on their way. Rows are never shorter than 44px and the whole row is the target, so the same list works under a thumb. The date is the short format with the exact timestamp in a tooltip - the pairing the drive explorer uses - because the full UTC string beside a size and a chip is what overflowed a phone-width column in the first draft. At most one chip for the same reason: a row that is both newest and the link's would otherwise carry two labels saying nearly the same thing. Opening the list shows the version already in hand and says what it is still looking for, rather than a spinner over nothing. A failed lookup keeps that row, says one line, and offers Retry - the file stays selected and downloadable throughout.
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Visit the preview URL for this PR (updated for commit 5352299): https://ardrive-web--pr2189-pe-9211-shared-file-zu4ilf9q.web.app (expires Sat, 29 Aug 2026 02:32:27 GMT) 🔥 via Firebase Hosting GitHub Action 🌎 Sign: a224ebaee2f0939e7665e7630e7d3d6cd7d0f8b0 |
A pinned link is the sharer saying which version they mean, not a limit on the recipient - who can reach every other version of the file on chain regardless, and whom the freshness banner already offers "View latest" with showSharedRevision as the way back. Pinning has always changed the default and the wording rather than the capability, so the list follows that rather than contradicting it. One word changes. The link's own row reads "Pinned" instead of "This link": "Pinned" says the sharer chose this version, "This link" says only that the link carried it, and on a pinned link the first is the fact worth knowing. It is also what makes the way back obvious after selecting something else. Nothing is disabled and nothing warns. Treating a sharer's preference as a constraint on the recipient would be false security - the same bytes are one query away - and it would put the list and the banner in disagreement.
The preview provider had no key, so it built its cubit once and kept it. Moving the download target left the preview showing whichever revision the page opened on while Download fetched a different one - two answers to "what am I looking at", and the quieter one was wrong. That was already reachable before the version list existed: "Get latest" moved the target the same way. Selecting from the list only made it easy to hit. Keyed on the bytes being previewed now, and wrapped in a 180ms fade so the swap reads as a replacement rather than a flicker - the pane is not moving, its contents are. Not covered by a widget test: FsEntryPreviewCubit reaches for DriveDao, ProfileCubit, ArweaveService and ConfigService at construction, which is why no test in this file opens the preview at all. Standing that up is worth doing, but not as a footnote to a one-line keying fix - so this one wants checking by hand on the preview build.
…-9211 "This file is stored permanently and can be downloaded any time." was the last line on the page, centred, in caption grey - marketing copy in a functional position, telling a recipient nothing they can act on. The frame already ends with a "What is ArDrive?" link to ardrive.io, so the page was closing on two gestures at the same idea and only one of them went anywhere. The link stays and the sentence goes. Removed from the raw transaction viewer as well: it carried the same line, in the same place, inside the same frame - so the same link already sat under it and the same argument applies. Leaving one page saying it and its sibling not would have been the odd outcome. The string is gone with its last use.
…9211 The 1970 was mine, from two commits ago. Seeding the list with the version the link named is what makes opening it instant - but a link carries no timestamps, so that row holds the epoch placeholder, and rendering it put "Jan 1, 1970" on screen until the real history arrived and quietly corrected it. Visibly, as it turns out. A row's label identifies its version, and normally that is its date. The seeded row has no date to give, so it is named by what it is - "This link", or "Pinned" - and does not repeat that as a chip. The placeholder is asked about rather than formatted: `SharedFileCubit.isUnknownDate` replaces a private sentinel the view could not see. The preview now opens on arrival. The page exists to show someone a file, so making them ask to see it was one click that should not exist; the pane is laid out either way on the desktop card, so this fills a box that was already there. The toggle stays, and a type that cannot be shown answers with its own sentence rather than nothing. That required the page's test harness to carry the four dependencies FsEntryPreviewCubit resolves at construction. Nothing opened a preview while it was opt-in, so the harness never had them and the whole preview path was untested - which is also why the keying fix in the previous commit shipped without one. They are inert here, but they are now there.
The selected row's mark was filled with the brand red, which made whichever version you were on the loudest thing in the card - an alert colour doing a selection job. It is the foreground colour now: still unmistakably filled, no longer shouting. "This link" described the mechanism that delivered the version rather than the version. `sharedFileSharedVersion` - "Shared" - already existed for exactly this row and is what the rest of the page speaks, so the string I added is gone and the existing one is back in use.
Hiding removed the widget subtree, which disposed the preview's cubit along with it - so reopening fetched the file from the gateway again. On a connection the gateway is rate limiting, that second fetch is one that can simply fail: hiding a file you already had could lose it. Both the desktop pane and the phone column keep the preview mounted now and only change whether it is shown. Nothing is cached anywhere new and no bytes are held that were not already held; the preview just never unloads while the page is open. Verified to bite: restoring the old unmount fails the new test, which asks the question directly - the provider is keyed on the bytes it previews, so whether that key is in the tree *is* whether the preview is still loaded.
…E-9211 Groundwork, no behaviour change: SharedFileDetailsContent and SharedFileVersionsContent hold the rows, and the two drawers become thin wrappers around them. The page is moving from stacked accordions - each of which resized the card when opened, so anything you clicked moved everything else - to one panel that swaps its contents in place. That panel needs the content without a disclosure wrapped around it, which is what these are.
…card PE-9211 Details and Version history were stacked accordions, so opening either pushed everything below it down - reading a date moved the download button. They are tabs in one panel now. The panel's height is fixed rather than fitted, because a panel sized to its tallest tab would still jump between them; content longer than that scrolls inside it. Wide matches the preview pane beside it so the two regions line up. The identifiers move one step further in. This file's own rule is that a recipient should be able to get their file without ever learning what a transaction id is, and a closed drawer was what kept that true - a tab that opens by default cannot, so file id, data and metadata transactions now sit behind their own "Transaction details" disclosure and the tab leads with what a person can use: type, dates, who shared it, licence. The version history is still asked for only when somebody looks - the trigger moved from opening a drawer to choosing the tab, and it is still answered once. The two drawer widgets stay for now: the raw transaction viewer mirrors their shape, and untangling that is not this change.
…ne PE-9211 Identity and Download move into a header across the top. They used to head a 368px left-hand column, which put the primary action in a third of the card's width and left the identity wrapping beside a preview pane twice its size. Up here they get the whole width, and the two regions below - the file, and everything about it - divide what is left. `_buildActions` returned one flat list that both layouts pulled apart differently, which is why the identity, the button, the preview and the drawers all had to agree on one order. It is four named pieces now, and each layout says its own arrangement in its own words. Cruft removed with it: SharedFileDetailsDrawer and SharedFileVersionsDrawer had no callers left once the panel took over, the 368px column width has nothing to size, and `_SharedFileDrawer.onExpansionChanged` existed only so the versions drawer could ask for its history - which the tab does now. One desktop layout assertion changed meaning rather than breaking: Download is no longer to the *left* of the preview pane, it is above it. The test says that instead.
… PE-9211 Follow-up polish on the restructured page: - drop the "permanent file sharing" tagline above the card; the logo already says whose page this is - give every list row in File details and Version history the same 44px height, so the two panels no longer look hand-spaced - show Date created and Last updated as friendly dates, with the exact UTC instant in a tooltip - let transaction details grow the card on a phone instead of scrolling inside it - the column already scrolls, and a second scrollbar under the thumb hid the rows it was meant to reveal - make the resting preview pane itself the control that opens the preview, and keep only Hide in the bar beneath it Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…E-9211 Verifying the previous commit's claim by measuring the rendered rows turned up one that was not standardized: the disclosure header came from an ExpansionTile, whose ListTile floor measured 58 against the 44 of the rows either side of it, so the list changed rhythm at the header and changed back after it. None of the knobs ExpansionTile exposes reach 44 - visualDensity moves in steps of four and overshoots to 42 - so the header is now built from the same row primitive as everything else in the panel. - rebuild the details disclosure as a 44px InkWell header with a rotating chevron, keeping its header/expanded semantics - add a test that measures every row in both tabs and the header, so the shared height is asserted rather than assumed - drop sharedFilePermanentFileSharing from all six locales; the tagline it belonged to is gone and nothing referenced the key Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #2186 — base is
PE-9210-sharing-hardening, so this diff is only the redesign.First slice of the shared file page layout work. The rest of the agreed design (auto-opening the preview, merging the two drawers into one details card, dropping the footer, collapsing to one column when there is nothing to preview) is not here yet.
What changed
The version list was read-only — date, size, and a marker on the one the link shared — while the only way to change what you downloaded was the freshness banner's two shortcuts. A list you can expand but not act on is a strange thing to have.
showRevisionis the general case behind those shortcuts, so a recipient can pick any version the file has. The banner stays honest because "a newer version exists" is re-derived from where the selection landed.Two things found while building it
The first draft overflowed a phone-width column by 43px — full UTC timestamp plus size plus two chips does not fit. The date is now the short format with the exact timestamp in a tooltip, the pairing the drive explorer already uses, and a row carries at most one chip.
It also deleted a spinner an existing test asserted on. The old loading state showed a
CircularProgressIndicatorover nothing; it now shows the version in hand and says what it is still looking for. That test was updated rather than worked around.Still open
What a pinned link should do here — a pinned link deliberately names one revision, and a freely selectable list makes pinning advisory. Discussed on the branch; not yet implemented either way.
🤖 Generated with Claude Code