* refactor: refactor support form
Refactor support form to make it easier to maintain:
- Split up large components into smaller components and hooks
- Lift state up so we don't have to do complex child/parent
state-syncing via useEffect
- Use nuqs parsing for consistent serialization/deserialization of
support form prefilled fields
* test: support form
Add comprehensive tests for support form
* fix(support form): project and org empty state
* Nit clean up
* More clean up
* cleannnn
* fix(support form): allow case-insensitive category in url
* clean(support form tests): remove unused param
* fix(support form): incorrect logic for sending affected services in payload
* clean(support form): use NO_ORG_MARKER and NO_PROJECT_MARKER instead of strings
* fix(support form): don't show upgrade cta if already on enterprise
---------
Co-authored-by: Joshen Lim <joshenlimek@gmail.com>
* fix: remove hidden guide pages from render
Guide pages hidden from nav are still rendered. This change removes them
from both build-time and on-demand rendering.
* fix: build llms script
The build llms script does not run in an environment where React is
available, so it must import from 'common/enabled-features', not from
'common', to avoid errors.
* fix: don't render hidden reference pages
Similar to guides, but for client SDK references. If a page is hidden
from the navigation (its feature flag is toggled off), don't render it
at all. This includes (a) at build time, (b) at request time, and (c) at
crawler request time.
* fix: types
Before:
There was a bug with middleware rewrites for reference pages without
crawler versions (basically all references except the client SDKs).
There was a branch that was not handled (the requesting user agent is a
a bot, but the reference is not a client SDK), so it failed through to
the base case of NextResponse.next(), which 404s as that page does not
exist for a path like /reference/api/v1-deploy-a-function
After:
Fixed the branch. If all of the following are true:
- Is a reference page
- Requesting user agent is a bot
- Reference is not a client SDK
Then it should follow the same path as a non-bot request, because there
is no bot-specific version. That means it should be rewritten to teh
slugless page: /reference/api/v1-deploya-function => /reference/api
* chore(docs,refs): prebuild self-hosted ref data
Pregenerate self-hosted ref data files, in the style of the client lib,
Management API, and CLI references. Preparatory step for migrating the
self-hosted references to App Router.
* refactor(docs): convert self-hosting to app router
Convert self-hosting reference pages to App Router.
* fix(docs,sitemap)
* chore(docs): preprocess management api specs
In preparation for App Router migration of Management API reference,
preprocess the Management API spec (both OpenAPI spec and common
sections), and write the processed data to file, in the style of the
other pregenerated reference data.
Details:
- Split reference section generation into separate functions for SDK, CLI, and API
- Add new function to generate API reference sections from OpenAPI spec
- Introduce mapEndpointsById function to create a map of API endpoints
- Update run function to execute all reference generation tasks in parallel
- Import necessary new dependencies and types
* refactor(docs): migrate management api reference to app router
* fix(docs): statically build management api reference page
* fix(docs): minor styling issues
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.
