-
Notifications
You must be signed in to change notification settings - Fork 1.3k
docs: S2 docs layout + general improvements #9159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
Build successful! 🎉 |
|
I think we need to add
|
snowystinger
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO I like it at the bottom, but it really depends on how prominent we want to make it
|
Build successful! 🎉 |
|
Build successful! 🎉 |
|
Build successful! 🎉 |
|
Build successful! 🎉 |
|
Build successful! 🎉 |
|
Build successful! 🎉 |
LFDanLu
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, approving for testing. Just one small comment
| // Reset pending state when navigation completes | ||
| useEffect(() => { | ||
| setPendingPage(null); | ||
| }, [currentPage.url]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you try useOptimistic for this? With that you setState and it will automatically reset whenever the props change.
| } | ||
|
|
||
| const [basePathname] = pathname.split('?'); | ||
| const [cleanPathname] = basePathname.split('#'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you parsed it with new URL then this shouldn't happen. If it didn't start with http then you could assume it's a relative url to the current location? new URL(urlOrPathname, location.href)
| if (raceResult === 'error') { | ||
| clearPendingPage(); | ||
| if (loadingShown) { | ||
| setNavigationLoading(false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wonder if we could use the promise returned by fetchRSC as the promise that we use() in the suspense boundary instead of managing a separate state here?
| let rscPath = basePath.replace('.html', '.rsc'); | ||
|
|
||
| // Use prefetched result if available, otherwise fetch | ||
| const prefetchedPromise = getPrefetchedPromise(rscPath); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One question is how long the prefetched promises are kept around? If someone loads a docs page and then comes back to the tab a week later and clicks a link, will it use a previously cached result or re-fetch? We may be able to rely on the browser cache to handle this as well – if we just call fetchRSC again it should return a cached result if it's still valid.
| let res = await fetchRSC<ReactElement>(pathname.replace('.html', '.rsc')); | ||
| raceResult = await Promise.race([ | ||
| fetchPromise.then(() => 'fast' as const).catch(() => 'error' as const), | ||
| delayPromise.then(() => 'slow' as const) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may not need the delay - we kinda want the skeleton to show up as fast as possible so the user knows something is happening, but just not when the result is already cached. We can experiment with it.
|
Build successful! 🎉 |
pointeroverlistener✅ Pull Request Checklist:
📝 Test Instructions:
🧢 Your Project: