Commit Graph
2 Commits
Author SHA1 Message Date
Danny White 4bda3bfe72 refactor(docs): unify homepage icon link tiles (#48317)
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Docs UI refactor.

## What is the current behavior?

Framework quickstarts and several other homepage grids used `IconPanel`
/ `IconPanelWithIconPicker`, which brought redundant tooltips
(duplicating the visible title), inconsistent hover treatment, and
circular icon tiles that didn't match the intended squarish look.

| Before |
| --- |
| <img width="1744" height="626" alt="CleanShot 2026-07-24 at 14 29
44@2x"
src="https://github.com/user-attachments/assets/1e145be2-19c9-4bd0-bf06-17516acbc774"
/> |

## What is the new behavior?

Introduces a shared `IconLink` used across the docs homepage (and
reference index) so icon+label tiles share the same composition and
hover: icon tile fill matches the surrounding surface (`surface-100`),
with a stronger border on hover, and the row uses `hover:bg-accent`.
Framework quickstarts keep the larger tile size; other sections keep the
smaller size. Also aligns Explore more GlassPanels with Build your
backend by using the same bordered background treatment.

| After |
| --- |
| <img width="2478" height="906" alt="CleanShot 2026-07-24 at 15 09
48@2x"
src="https://github.com/user-attachments/assets/dd516845-c162-47e4-8b86-9a7fa0e73290"
/> |

## Additional context

Removes the unused `IconPanelWithIconPicker` wrapper now that
homepage/reference consumers go through `IconLink`.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Added reusable `IconLink` UI for consistent docs tiles, including
`IconLinkList`, menu icon, and light/dark icon rendering.
* Introduced `FrameworkQuickstarts` to generate quickstart links based
on feature-flag-enabled SDKs.
* **UI / Improvements**
* Updated the docs home and API reference pages to use the new
list-based icon-link layout.
* Refreshed migration guides and “Explore more”/self-hosting sections
(including accessibility and updated CTA text).
* **Bug Fixes**
  * Migration guide items now omit entries missing required details.
* **Chores / Cleanup**
* Removed the older icon panel picker-based UI component and its usage.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
2026-07-28 15:12:13 +10:00
Charis fc164b5d07 Refactor/app router refs (#28095)
Migrates client SDK References to App Router. (Management and CLI API references aren't migrated yet, nor are self-hosting config references.)

Some notes:

Big changes to the way crawler pages are built and individual section URLs (e.g., javascript/select) are served. All of these used to be SSG-generated pages, but the number of heavy pages was just too much to handle -- slow as molasses and my laptop sounded like it was taking off, and CI sometimes refuses to build it all at all.

Tried various tricks with caching and pre-generating data but no dice.

So I changed to only building one copy of each SDK+version page, then serving the sub-URLs through a response rewrite. That's for the actual user-visible pages.

For the bot pages, each sub-URL needs to be its own page, but prebuilding it doesn't work, and rendering on demand from React components is too slow (looking for super-fast response here for SEO). Instead I changed to using an API route that serves very minimal, hand-crafted HTML. It looks ugly, but it's purely for the search bots.

You can test what bots see by running curl --user-agent "Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A5376e Safari/8536.25 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" <URL_OF_PAGE>

Also added some smoke tests to run against prod for the crawler routes, since we don't keep an eye on those regularly, and Vercel config changes could surprise-break them. Tested the meta images on Open Graph and all seems to work fine.

With this approach, full production builds are really fast: ~5 minutes

Starts using the new type spec handling, which is better at finding params automatically, so I could remove some of the manually written ones from the spec files.
2024-08-13 16:12:59 -04:00