* docs: fix a mis-match between the sample code and sample response
* fix onAuthStateChange unsubscribe code
* Revert "fix onAuthStateChange unsubscribe code"
This reverts commit 8d438ae145.
* fix code sample for unsubscribing in Flutter
Now that production builds are fast, let's remove the preview build
shortcuts. (One of them didn't work anyway.) Having different preview
and production builds can lead to edge case bugs making it into master,
and we won't see much further build time improvement that's worth the
risk.
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.
* whale d2
* video id
* cleanup meetups
* realtime: Blog for Realtime Broadcast and Presence Authz (#27691)
* realtime: Blog for Realtime Broadcast and Presence Authz
Blog post to be used for Realtime Broadcast and Presence authorization
---------
Co-authored-by: Wen Bo Xie <wenbo.xie3@gmail.com>
* add lw tags to blog post
* Adds edits
* prettier run
---------
Co-authored-by: Filipe Cabaço <filipe@supabase.io>
Co-authored-by: Wen Bo Xie <wenbo.xie3@gmail.com>
Co-authored-by: Copple <10214025+kiwicopple@users.noreply.github.com>
Co-authored-by: Filipe Cabaço <filipecabaco@gmail.com>
* exclude dart, python, and swift from error codes menu
* Update the error code doc to be client lib agnostic
* run formatter
* Add a filter to filter out section items
* Update apps/docs/components/Navigation/NavigationMenu/NavigationMenuRefList.tsx
* docs: move error codes table in a separate component
* Add auth error codes section for kotlin
Our syntax highlighter doesn't recognize HTML (tried to install it but it's not
on the lsit of supported languages) and this somehow causes the server and
client to make different highlighting decisions, with the server attempting to
highlight the code block and the client not.
Removing the html language specifier removes the hydration error (and since the
client never properly highlighted it anyway, we don't lose much in terms of
syntax highlighting.)
* Change Snaplet link to Github repo
Updated guide to reflect Snaplet seed changes
Mention tips for users that do not have an ORM setup
Added Snaplet to accept.txt file
* Add npm to accept.txt
* Adding mdx formating suggestions from code review
---------
Co-authored-by: Charis <26616127+charislam@users.noreply.github.com>
Replace docs command menu with Command Menu V2 from ui-patterns/CommandMenu.
This introduces the prepackaged folder for the shared Command Menu, which contains commands that are shared across the sites (for example, docs search, theme switcher).
Commands that are only applicable to a single site are now defined within that site's own app folder (put them wherever makes sense for your app folder organization, as long as you use the hooks within a global CommandProvider it will work...)
Tested navigating around, using search and AI on laptop and mobile.
Tyler