docs: proofreading

FEATURES.md

@@ -30,10 +30,10 @@ Unique Vike features:
    - Especially important for large companies that already have a deployment architecture
  - Vike allows the user to use different UI frameworks for the same app
    - For example, a Vike sponsor uses Vike to use Solid for all its pages except for one page that uses React because it needs a React library that doesn't exist for Solid
-     - Important for Solid: for React users that are tempted to use Solid, Solid can sell the story "try Solid while being able to fallback to React, e.g. if a page needs some React library".
+     - Important for Solid: for React users that are tempted to use Solid, Solid can sell the story "try Solid while being able to fall back to React, e.g. if a page needs some React library".
  - Users can build a custom [Framework-as-a-Product](https://vike.land/#framework-as-a-product). (Vike has been designed so that frameworks can be built on top of it.)
    - [Custom configs](https://vike.dev/meta)
- - Low-level primites allowing users to deeply integrate with data fetching tools.
+ - Low-level primitives allowing users to deeply integrate with data fetching tools.
    - For example, Vike sponsors use it to deeply integrate Relay. (Facebook's internal framework deeply integrates with Relay in ways that aren't possible with Next.js.)
  - URL rewriting for both [novel DX and novel UX](https://twitter.com/brillout/status/1687431520569425920) around authentication and authorization
 
@@ -57,20 +57,20 @@ Minor features that can be life changing for some users:
 - Low-level i18n hooks which allow to implement i18n without compromise (not a single user has reported a missing i18n use case, covering all i18n use cases is hard)
 - Not only Route Guards but also Route Functions (define your route with a function for full programmatic flexibility)
 - `pageContext.isBackwardsNavigation` (https://vike.dev/pageContext) for backwards/forward page transition animations
-- Vike can be loaded twice (or more) on the server-side, (some deployement architectures need this)
-- Catches and interupts infinite loops of URL redirections and URL rewrites
+- Vike can be loaded twice (or more) on the server-side, (some deployment architectures need this)
+- Catches and interrupts infinite loops of URL redirections and URL rewrites
 
 And lots of details:
 - [Automatic frontend deployment synchronization](https://vike.dev/deploy-sync)
 - `93` warning messages that help the user. For example:
   - Warning is shown when a hook takes more than 4 seconds to resolve (avoiding the user to ask himself "why is my Vike app hanging?")
   - Warning is shown when client runtime is included twice in the bundle
   - Warning wrongly using `process.env.NODE_ENV`, including docs: https://vike.dev/NODE_ENV
-- `294` helpul error messages. For example:
+- `294` helpful error messages. For example:
   - Upon a 404 in dev, the complete list of routes is shown
   - Helpful error when different versions of Vike are loaded
   - Typo in an option name (with "Did you mean xxx instead?")
-- Proper development error hanlding (hard to achieve, especially since Vite is bogus about it)
+- Proper development error handling (hard to achieve, especially since Vite is bogus about it)
 
 Misc:
 - `throw Render()`

README.md

@@ -3,7 +3,7 @@
 
 *Like Next.js/Nuxt but as do-one-thing-do-it-well Vite plugin.*
 
-**Introducion & documentation** :arrow_right: [vike.dev](https://vike.dev)
+**Introduction & documentation** :arrow_right: [vike.dev](https://vike.dev)
 <br/>
 **Examples (official)** :arrow_right: [examples/](https://github.com/vikejs/vike/tree/main/examples)
 <br/>

docs/components/routing/ClientRouting.mdx

@@ -1,6 +1,6 @@
 import { Link } from '@brillout/docpress'
 
-By default Vike does Server Routing. We can opt into Client Routing by setting the <Link text={<><code>clientRouting</code> option</>} href="/clientRouting" /> to `true`.
+By default, Vike does Server Routing. We can opt into Client Routing by setting the <Link text={<><code>clientRouting</code> option</>} href="/clientRouting" /> to `true`.
 
 *Client(-side) Routing* denotes the practice of implementing page navigation on the client-side:
 when the user navigates to a new page,

docs/pages/SPA-vs-SSR.page.server.mdx

@@ -37,7 +37,7 @@ SPA advantages:
    > We can remove the need for a production Node.js server for SSR apps by using pre-rendering.
  - Decreased backend workload.
 
-While for certain types of pages, such as an Admin Panel where there is a clear choice in favor of SPA, there often isn't a clear cut whether we should use SPA or SSR.
+While for certain types of pages, such as an Admin Panel where there is a clear choice in favor of SPA, there often isn't a clear-cut whether we should use SPA or SSR.
 
 
 ## SSR

docs/pages/client-runtimes-conflict.page.server.mdx

@@ -14,7 +14,7 @@ Then the problem is likely due to one the following.
 
    // This will lead to the warning above. We recommend against this practice: not only because
    // of the above warning but also because, in general, a given page should only load what is
-   // striclty needed for that page. (Initial page load speed is usually more critical than
+   // strictly needed for that page. (Initial page load speed is usually more critical than
    // subsequent page load speed.)
    const rollupOptions = {
      output: {

docs/pages/clientRouting.page.server.mdx

@@ -50,8 +50,6 @@ export { onPageTransitionEnd }
 // subsequent page navigation).
 export { onHydrationEnd }
 
-the user navigates to the render() hook the first page finishes rendering render())
-
 import { renderToDom, hydrateDom } from 'some-ui-framework'
 
 async function render(pageContext) {
@@ -65,7 +63,6 @@ async function render(pageContext) {
       // We render a new page. (When the user navigates to a new page.)
       await renderToDom(pageContext.Page)
     }
-  }
 }
 
 async function onPageTransitionStart(pageContext) {
@@ -271,8 +268,8 @@ export { onPageTransitionEnd }
 export { onHydrationEnd }
 
 import type {
-  OnPageTransitionStartAsync
-  OnPageTransitionEndAsync
+  OnPageTransitionStartAsync,
+  OnPageTransitionEndAsync,
   OnHydrationEndAsync
 } from 'vike/types'
 

docs/pages/debug.page.server.mdx

@@ -19,7 +19,7 @@ DEBUG=vike:log,vike:error,vike:stream npm run dev
 
 > These debug logs allow you to understand how Vike thinks of your app. For example, to figure out why your app returns a `404`, use `vike:routing` and `vike:pageFiles`.
 
-There are more debug logs (`vike:glob`, `vike:extractAssets`, ...) but these aren't user friendly as they are meant for Vike maintainers.
+There are more debug logs (`vike:glob`, `vike:extractAssets`, ...) but these aren't user-friendly as they are meant for Vike maintainers.
 
 > If you want more debug logs, add a comment at [#249](https://github.com/vikejs/vike/issues/249).
 

docs/pages/doNotPrerender.page.server.mdx

@@ -37,7 +37,7 @@ export const doNotPrerender = false
 This is especially handy with <Link text="Domain-Driven File Structure" href='/file-structure#domain-driven' />:
 
 ```js
-// /pages/mareting/_default.page.server.js
+// /pages/marketing/_default.page.server.js
 
 // We use Domain-Driven File Structure and `_default.page.server.js` applies to
 // all our marketing pages.

docs/pages/docker.page.server.mdx

@@ -25,7 +25,7 @@ See also:
 
 If we want to use Docker for development as well, we need to properly configure Docker for Vite's HMR port.
 
-If we use Windows with [WSL](https://docs.microsoft.com/en-us/windows/wsl/), we need to to configure [`chokidar`](https://github.com/paulmillr/chokidar) to use polling. (Vite uses `chokidar`.)
+If we use Windows with [WSL](https://docs.microsoft.com/en-us/windows/wsl/), we need to configure [`chokidar`](https://github.com/paulmillr/chokidar) to use polling. (Vite uses `chokidar`.)
 
 ```json
 // package.json

docs/pages/errors.page.server.mdx

@@ -11,7 +11,7 @@ import { renderPage } from 'vike/server'
 app.get('*', async (req, res) => {
   const pageContext = await renderPage({ urlOriginal: req.url })
 
-  // An error occured during server-side rendering
+  // An error occurred during server-side rendering
   if (pageContext.errorWhileRendering) {
     someErrorTracker(pageContext.errorWhileRendering)
   }

docs/pages/exports.page.server.mdx

@@ -180,7 +180,7 @@ function render(pageContext) {
 
 ## Example: Meta Data
 
-We can also use a custom export `pageContext.export.meta` to define the meta data of a page.
+We can also use a custom export `pageContext.export.meta` to define the metadata of a page.
 
 ```js
 // /pages/product.page.js

docs/pages/filesystem-routing.page.server.mdx

@@ -1,4 +1,4 @@
-By default Vike does Filesystem Routing: the URL of a page is determined based on where its `.page.js` file is located.
+By default, Vike does Filesystem Routing: the URL of a page is determined based on where its `.page.js` file is located.
 
 ```bash
 FILESYSTEM                        URL

docs/pages/grpc.page.server.mdx

@@ -3,8 +3,8 @@ import { Link } from '@brillout/docpress'
 There are no [gRPC](https://github.com/grpc) client for the browser.
 (Protocol Buffers does not support the browser.)
 
-This means we cannot call gRPC enpdoints directly from the browser;
-we always need to call gRPC enpdoints from our Node.js server.
+This means we cannot call gRPC endpoints directly from the browser;
+we always need to call gRPC endpoints from our Node.js server.
 
 For fetching data,
 we can simply use a <Link text={<code>onBeforeRender()</code>} href="/data-fetching" /> hook,

docs/pages/hapi.page.server.mdx

@@ -2,7 +2,7 @@ import { Link } from '@brillout/docpress'
 
 We can use Vike as well with [hapi](https://hapi.dev/).
 
-> hapi is a [Express.js](https://expressjs.com/) alternative.
+> hapi is an [Express.js](https://expressjs.com/) alternative.
 
 We recommend the following setup.
 

docs/pages/hydration-mismatch.page.server.mdx

@@ -14,7 +14,7 @@ Hydration mismatches can induce performance degradations and bugs and should the
 
 Upon a hydration mismatch, Vue throws following errors in the browser:
 
-```js
+```
 [Vue warn]: Hydration text mismatch:
  - Client: "some content"
  - Server: "some other content"

docs/pages/index/features/DeployAnywhere.mdx

@@ -15,4 +15,4 @@ You can also pre-render your app to remove the need for a production Node.js ser
 
 <h3>Cloudflare Workers + Vike = <Emoji name="red-heart" /></h3>
 
-Thanks to Vike's lean architecture, your app is much less limited by Cloudflare Workers's 1MB bundle size limit.
+Thanks to Vike's lean architecture, your app is much less limited by Cloudflare Workers' 1MB bundle size limit.

docs/pages/integration.page.server.mdx

@@ -29,7 +29,7 @@ export { render }
 async function render(pageContext) {
   // `Page` is the `export { Page }` of our `*.page.js` files;
   // Vike doesn't do anything with `Page` and just makes it available as
-  // `pageContex.Page`; we can export any `Page` value we want and do whatever we want with it.
+  // `pageContext.Page`; we can export any `Page` value we want and do whatever we want with it.
   const { Page } = pageContext
 
   // We control how we use our UI framework to render our pages to HTML
@@ -58,7 +58,7 @@ export { render }
 
 import { hydrateDom } from 'some-ui-framework'
 
-async render(pageContex) {
+async function render(pageContext) {
   const { Page } = pageContext
   // We control how our pages are hydrated
   await hydrateDom(Page)
@@ -87,16 +87,16 @@ Sentry.init()
 // And also for initializing a Service Worker.
 navigator.serviceWorker.register(/* ... */)
 
-async render(pageContex) {
+async function render(pageContext) {
   // Here we can integrate performance measurement tools, e.g. to measure hydration performance
-  const { Page } = pageContex
+  const { Page } = pageContext
   await hydrateDom(Page)
   init()
 }
 
 function init() {
   // After hydration we usually initialize vanilla JS component libraries, for example tooltips
-  tooltip.init(document.querySelectorAll('.tooltip')
+  tooltip.init(document.querySelectorAll('.tooltip'))
   // Or some vanilla JS modal library
   $('.my-modals').modal()
 }

docs/pages/markdown.page.server.mdx

@@ -213,4 +213,4 @@ A frequent need when using markdown is to show the list of markdown pages to you
 
 To be able to do so, we recommend defining a file `metadata.js` that contains the metadata of all your markdown pages, see <Link href="#metadata" />.
 
-Another apporach is to use [`import.meta.glob()`](https://vitejs.dev/guide/features.html#glob-import) to retrieve the list of markdown files, but we usually recommend against this approach. The problem is that, in order to retrieve the metadata of all your markdown files, you'd need to load the *entire* code of *all* your markdown files, which contradicts <Link text="Vite's lazy-transpiling approach" href="/lazy-transpiling" /> and dramatically degrading Vite's development DX speed.
+Another approach is to use [`import.meta.glob()`](https://vitejs.dev/guide/features.html#glob-import) to retrieve the list of markdown files, but we usually recommend against this approach. The problem is that, in order to retrieve the metadata of all your markdown files, you'd need to load the *entire* code of *all* your markdown files, which contradicts <Link text="Vite's lazy-transpiling approach" href="/lazy-transpiling" /> and dramatically degrading Vite's development DX speed.

docs/pages/meta.page.server.mdx

@@ -91,7 +91,7 @@ export default {
     onBeforeRender: {
       // By default, the onBeforeRender() hook is always loaded and executed only on the
       // server-side. By using the meta config we can make it isomorphic instead:
-      // onBeforeRender() is loaded and executed as well on the cient-side.
+      // onBeforeRender() is loaded and executed as well on the client-side.
       env: 'server-and-client'
     }
   }
@@ -107,7 +107,7 @@ For extra convenience, we can create a `onBeforeRenderIsomorph` toggle:
 
 import type { Config, Effect } from 'vike/types'
 
-const onBeforeRenderIsomorphEffect: Effect = ({ configDefinedAt, configValue }) {
+const onBeforeRenderIsomorphEffect: Effect = ({ configDefinedAt, configValue }) => {
   if (typeof configValue !== 'boolean') {
     throw new Error(`${configDefinedAt} should be a boolean`)
   }
@@ -134,5 +134,5 @@ export default {
 
 Example:
  - [/examples/react-full-v1/](https://github.com/vikejs/vike/blob/01cc674498ea8baa289bfccb633d04b4d6cc7958/examples/react-full-v1/)
-   - Config defintion: [/renderer/+config.h.ts > `meta.onBeforeRenderIsomorph`](https://github.com/vikejs/vike/blob/01cc674498ea8baa289bfccb633d04b4d6cc7958/examples/react-full-v1/renderer/+config.h.ts#L14-L33)
+   - Config definition: [/renderer/+config.h.ts > `meta.onBeforeRenderIsomorph`](https://github.com/vikejs/vike/blob/01cc674498ea8baa289bfccb633d04b4d6cc7958/examples/react-full-v1/renderer/+config.h.ts#L14-L33)
    - Config usage: [/pages/star-wars/@id/+onBeforeRenderIsomorph.ts](https://github.com/vikejs/vike/blob/01cc674498ea8baa289bfccb633d04b4d6cc7958/examples/react-full-v1/pages/star-wars/@id/+onBeforeRenderIsomorph.ts)

docs/pages/migration/0.5.page.server.mdx

@@ -1,3 +1,3 @@
 If you use:
- - TypeScript, make sure your `tsconfig.json` doens't transpile to CJS (e.g. make sure `tsconfig.json#compilerOptions.module` isn't set to `CommonJS`).
+ - TypeScript, make sure your `tsconfig.json` doesn't transpile to CJS (e.g. make sure `tsconfig.json#compilerOptions.module` isn't set to `CommonJS`).
  - `ts-node`, make sure your `tsconfig.json#ts-node` doesn't transpile to CJS (e.g. make sure `tsconfig.json#ts-node.compilerOptions.module` isn't set to `CommonJS`)

docs/pages/onBeforePrerenderStart.page.server.mdx

@@ -39,7 +39,7 @@ const onBeforePrerenderStart: OnBeforePrerenderStartAsync = async (
     url: '/movies',
     pageContext: {
       pageProps: {
-        movieList: movies.map(({id, title}) => ({id, title})
+        movieList: movies.map(({id, title}) => ({id, title}))
       }
     }
   }

docs/pages/onBeforeRender-multiple.page.server.mdx

@@ -33,7 +33,7 @@ function onBeforeRender(pageContext) {
 
 export { onBeforeRender }
 
-function onBeforeRender(pageContext) {
+async function onBeforeRender(pageContext) {
   if (Math.random() > 0.5) {
     // Run the `onBeforeRender()` hook of `some.page.server.js`
     const { pageContext: pageContextAddendum } =
@@ -57,7 +57,7 @@ export const skipOnBeforeRenderDefaultHook = false
 
 export { onBeforeRender }
 
-function onBeforeRender(pageContext) {
+async function onBeforeRender(pageContext) {
   if (Math.random() > 0.5) {
     // Run the `onBeforeRender()` hooks of `_default.page.server.js` and `some.page.server.js`.
     // (Note that unlike `pageContext.runOnBeforeRenderPageHook(pageContext)`, we cannot pass
@@ -75,7 +75,7 @@ function onBeforeRender(pageContext) {
 
 export { onBeforeRender }
 
-function onBeforeRender(pageContext) {
+async function onBeforeRender(pageContext) {
   if (Math.random() > 0.5) {
     // Run the `onBeforeRender()` hook of `some.page.js`
     const { pageContext: pageContextAddendum } =

docs/pages/pageContext-manipulation.page.server.mdx

@@ -5,7 +5,7 @@ The hooks [`onBeforeRender()`](/onBeforeRender), [`render()`](/render-hook), and
 
 export { onBeforeRender }
 
-function onBeforeRender(pageContext) {
+async function onBeforeRender(pageContext) {
   const starWarsMovies = await getStarWarsMovies()
   return {
     pageContext: {

docs/pages/pageContext.page.server.mdx

@@ -62,7 +62,7 @@ Built-in properties:
  - **`pageContext.isHydration`**: Whether the current page is already rendered to HTML. When using <Link href="/client-routing" noBreadcrumb={true} />, the value is usually `true` for the first page the user navigates to, and `false` for any subsequent navigation. (When using <Link href="/server-routing" noBreadcrumb={true} />, the value is always `true`.)
  - **`pageContext.isBackwardNavigation`**: Whether the user is navigating back in history. The value is `true` when the user clicks on his browser's backward navigation button, or when invoking `history.back()`. The `isBackwardNavigation` property only works with Client Routing. (The value is always `null` when using Server Routing.)
  - **`pageContext.is404`**: If an error occurs, whether the error is a `404 Page Not Found` or a `500 Internal Error`, see <Link href="/error-page" />.
- - **`pageContext.isClientSideNavigation`**: Whether the page was navigated by the the client-side router. In other words, when using <Link href="/client-routing" noBreadcrumb={true} />, the value is `false` for the first page the user visits, and `true` for any subsequent navigation. (When using <Link href="/server-routing" noBreadcrumb={true} />, the value is always `false`.)
+ - **`pageContext.isClientSideNavigation`**: Whether the page was navigated by the client-side router. In other words, when using <Link href="/client-routing" noBreadcrumb={true} />, the value is `false` for the first page the user visits, and `true` for any subsequent navigation. (When using <Link href="/server-routing" noBreadcrumb={true} />, the value is always `false`.)
  - **`pageContext.abortReason`**: Set by <Link href="/render" text={<code>throw render()</code>} /> and used by the <Link text="error page" href="/error-page" />.
  - **`pageContext.abortStatusCode`**: Set by <Link href="/render" text={<code>throw render()</code>} /> and used by the <Link text="error page" href="/error-page" />.
 
@@ -79,7 +79,7 @@ You can define custom `pageContext` properties.
           // **** Custom pageContext properties ****
           // ***************************************
           // Common use case: make fetched data available over pageContext
-          someData: { product: { id: 123, name: 'MacBook' } }
+          someData: { product: { id: 123, name: 'MacBook' } },
           // Or any other custom property you want
           someCustomProp: 'some-value'
         }
@@ -157,7 +157,7 @@ When using <Link href="/client-routing" noBreadcrumb={true} />, the following ar
 ```ts
 import type {
   // For code loaded in client and server
-  PageContext
+  PageContext,
   // For code loaded in client only
   PageContextClient,
   // For code loaded in server only

docs/pages/path-aliases.page.server.mdx

@@ -35,7 +35,7 @@ export default {
 ```
 
 > The Vite config `resolve.alias` only applies to files that are processed by Vite.
-> Note that that some of your server files may not be processed by Vite,
+> Note that some of your server files may not be processed by Vite,
 > see the [Node.js section below](#node-js).
 
 We recommend following the [Node.js convention](https://nodejs.org/api/packages.html#subpath-imports:~:text=must%20always%20start%20with%20%23%20to%20ensure%20they%20are%20disambiguated%20from%20external%20package%20specifiers) to prefix path aliases with the special character `#`.

docs/pages/preload.page.server.mdx

@@ -19,7 +19,7 @@ import { renderPage } from 'vike/server'
 app.get('*', async (req, res) => {
   const pageContext = await renderPage({ urlOriginal: req.originalUrl } )
   const { earlyHints } = pageContext.httpResponse
-  // For exampe with Node.js 18:
+  // For example with Node.js 18:
   res.writeEarlyHints({ link: earlyHints.map((e) => e.earlyHintLink) })
 })
 ```