docs: S2 docs layout + general improvements #9159
Conversation
|
Build successful! 🎉 |
|
I think we need to add |
snowystinger
left a comment
snowystinger
left a comment
There was a problem hiding this comment.
It's strange, there's still a delay moving to the new page with the skeleton. Then the skeleton appears and disappears so fast that it doesn't feel like it's helping with the transition.
|
@majornista fyi I removed the sticky positioning in this PR: #9135 |
devongovett
left a comment
devongovett
left a comment
There was a problem hiding this comment.
nice! would be cool if we could get optimistic updates working for the sidenav, so when you click a link the selection moves instantly as soon as the skeleton appears. might be able to do that with useOptimistic. ideally the skeleton would also not appear at all if the page load is fast.
packages/dev/s2-docs/src/Layout.tsx
Outdated
| </ScrollableToc> | ||
| <div className={style({flexShrink: 0})}> | ||
| <Divider size="S" styles={style({marginY: 12})} /> | ||
| <MarkdownMenu url={currentPage.url} /> |
There was a problem hiding this comment.
Question for the team: do we prefer this at the bottom of the page or at the top (i.e. above "on this page")? Most sites seem to have it at the top. I don't mind the bottom but it's a little less prominent. Also moves around a bit depending on the length of the toc.
There was a problem hiding this comment.
My reasoning was that the table of contents is more useful most of the time, so it's better when scanning to read that first. Also if we end up adding more actions (feedback button, etc.) it might crowd the top. Definitely open to changing this though.
Also for pages with many sections it renders at the bottom and the ToC has scrolling.
There was a problem hiding this comment.
IMO I like it at the bottom, but it really depends on how prominent we want to make it
|
Build successful! 🎉 |
reidbarber
changed the title
|
Build successful! 🎉 |
|
Build successful! 🎉 |
reidbarber
changed the title
|
Build successful! 🎉 |
|
Looks like title string matching isn't be preferred over tags? i think it's matching "info" in tooltip over "fo" in "forms" |
|
Build successful! 🎉 |
reidbarber
dismissed stale reviews from LFDanLu and snowystinger
via
ff3c90c
|
Build successful! 🎉 |
* close SearchMenu on client navigation * add footer * made Nav and ToC widths static * fix min-height issue on mobile * show Toast if route can't load * add toast for clipboard copy failures * fix React insertion effect * improve markdown menu * add skeleton loading for client routing * copy update * remote extra startTransitions and use use hook * improve skeleton loading and optimistic render link selection + ToC * add delay to showing skeleton * fix getPageInfo logic * try fixing getPageInfo again * try fixing normalizePathname on build * add prefetch onPressStart * revert optimistic UI and show error toast if fetch fails * fix skeleton title * don't clear targetPathname until new navigation * move prefetch to a global pointerover listener * close search menu when navigation starts * show skeleton loading immediately when navigation starts * re-use tag group in SearchMenu and MobileSearchMenu * fix and extract out search logic * remove blog and releases index pages from search * reduce size of icons in dnd blog post example * fix Forms password example * centralize search logic * add escapeKeyBehavior="none" to tag groups * fix toc scroll mask * simplify pathname logic * remove promises from prefetch cache once resolved * use useOptimistic * use fetchRSC promise as loading source * avoid navigation race conditions * prefetch on focus (same as pointerover) * function for checking if client link * fix search results sorting for All tag * add message to currentAbortController.abort * lint
pointeroverandfocuslistenersFixes from testing:
✅ Pull Request Checklist:
📝 Test Instructions:
🧢 Your Project: