diff --git a/packages/docs/src/routes/api/qwik/api.json b/packages/docs/src/routes/api/qwik/api.json
index ca2f30ce52f..1ca0f3d98f9 100644
--- a/packages/docs/src/routes/api/qwik/api.json
+++ b/packages/docs/src/routes/api/qwik/api.json
@@ -189,7 +189,7 @@
}
],
"kind": "Interface",
- "content": "Low-level API for platform abstraction.\n\nDifferent platforms (browser, node, service workers) may have different ways of handling things such as `requestAnimationFrame` and imports. To make Qwik platform-independent Qwik uses the `CorePlatform` API to access the platform API.\n\n`CorePlatform` also is responsible for importing symbols. The import map is different on the client (browser) then on the server. For this reason, the server has a manifest that is used to map symbols to javascript chunks. The manifest is encapsulated in `CorePlatform`, for this reason, the `CorePlatform` can't be global as there may be multiple applications running at server concurrently.\n\nThis is a low-level API and there should not be a need for you to access this.\n\n\n```typescript\nexport interface CorePlatform \n```\n\n\n| Property | Modifiers | Type | Description |\n| --- | --- | --- | --- |\n| [chunkForSymbol](#) | | (symbolName: string, chunk: string \\| null) => readonly \\[symbol: string, chunk: string\\] \\| undefined |
Retrieve chunk name for the symbol.
When the application is running on the server the symbols may be imported from different files (as server build is typically a single javascript chunk.) For this reason, it is necessary to convert the chunks from server format to client (browser) format. This is done by looking up symbols (which are globally unique) in the manifest. (Manifest is the mapping of symbols to the client chunk names.)
Qwik needs to lazy load data and closures. For this Qwik uses QRLs that are serializable references of resources that are needed. The QRLs contain all the information necessary to retrieved the reference using importSymbol.
Why not use import()? Because import() is relative to the current file, and the current file is always the Qwik framework. So QRLs have additional information that allows them to serialize imports relative to application base rather than the Qwik framework file.
|\n| [isServer](#) | | boolean | True of running on the server platform. |\n| [nextTick](#) | | (fn: () => any) => Promise<any> | Perform operation on next tick. |\n| [raf](#) | | (fn: () => any) => Promise<any> | Perform operation on next request-animation-frame. |",
+ "content": "Low-level API for platform abstraction.\n\nDifferent platforms (browser, node, service workers) may have different ways of handling things such as `requestAnimationFrame` and imports. To make Qwik platform-independent Qwik uses the `CorePlatform` API to access the platform API.\n\n`CorePlatform` also is responsible for importing symbols. The import map is different on the client (browser) then on the server. For this reason, the server has a manifest that is used to map symbols to javascript chunks. The manifest is encapsulated in `CorePlatform`, for this reason, the `CorePlatform` can't be global as there may be multiple applications running at server concurrently.\n\nThis is a low-level API and there should not be a need for you to access this.\n\n\n```typescript\nexport interface CorePlatform \n```\n\n\n| Property | Modifiers | Type | Description |\n| --- | --- | --- | --- |\n| [chunkForSymbol](#) | | (symbolName: string, chunk: string \\| null) => readonly \\[symbol: string, chunk: string\\] \\| undefined |
Retrieve chunk name for the symbol.
When the application is running on the server the symbols may be imported from different files (as server build is typically a single javascript chunk.) For this reason, it is necessary to convert the chunks from server format to client (browser) format. This is done by looking up symbols (which are globally unique) in the manifest. (Manifest is the mapping of symbols to the client chunk names.)
Qwik needs to lazy load data and closures. For this Qwik uses QRLs that are serializable references of resources that are needed. The QRLs contain all the information necessary to retrieve the reference using importSymbol.
Why not use import()? Because import() is relative to the current file, and the current file is always the Qwik framework. So QRLs have additional information that allows them to serialize imports relative to application base rather than the Qwik framework file.
|\n| [isServer](#) | | boolean | True of running on the server platform. |\n| [nextTick](#) | | (fn: () => any) => Promise<any> | Perform operation on next tick. |\n| [raf](#) | | (fn: () => any) => Promise<any> | Perform operation on next request-animation-frame. |",
"editUrl": "https://github.com/BuilderIO/qwik/tree/main/packages/qwik/src/core/platform/types.ts",
"mdFile": "qwik.coreplatform.md"
},
diff --git a/packages/docs/src/routes/api/qwik/index.md b/packages/docs/src/routes/api/qwik/index.md
index e526221625f..aa92465d56e 100644
--- a/packages/docs/src/routes/api/qwik/index.md
+++ b/packages/docs/src/routes/api/qwik/index.md
@@ -398,13 +398,13 @@ This is a low-level API and there should not be a need for you to access this.
export interface CorePlatform
```
-| Property | Modifiers | Type | Description |
-| ------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| [chunkForSymbol](#) | | (symbolName: string, chunk: string \| null) => readonly [symbol: string, chunk: string] \| undefined |
Retrieve chunk name for the symbol.
When the application is running on the server the symbols may be imported from different files (as server build is typically a single javascript chunk.) For this reason, it is necessary to convert the chunks from server format to client (browser) format. This is done by looking up symbols (which are globally unique) in the manifest. (Manifest is the mapping of symbols to the client chunk names.)
Qwik needs to lazy load data and closures. For this Qwik uses QRLs that are serializable references of resources that are needed. The QRLs contain all the information necessary to retrieved the reference using importSymbol.
Why not use import()? Because import() is relative to the current file, and the current file is always the Qwik framework. So QRLs have additional information that allows them to serialize imports relative to application base rather than the Qwik framework file.
|
-| [isServer](#) | | boolean | True of running on the server platform. |
-| [nextTick](#) | | (fn: () => any) => Promise<any> | Perform operation on next tick. |
-| [raf](#) | | (fn: () => any) => Promise<any> | Perform operation on next request-animation-frame. |
+| Property | Modifiers | Type | Description |
+| ------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [chunkForSymbol](#) | | (symbolName: string, chunk: string \| null) => readonly [symbol: string, chunk: string] \| undefined |
Retrieve chunk name for the symbol.
When the application is running on the server the symbols may be imported from different files (as server build is typically a single javascript chunk.) For this reason, it is necessary to convert the chunks from server format to client (browser) format. This is done by looking up symbols (which are globally unique) in the manifest. (Manifest is the mapping of symbols to the client chunk names.)
Qwik needs to lazy load data and closures. For this Qwik uses QRLs that are serializable references of resources that are needed. The QRLs contain all the information necessary to retrieve the reference using importSymbol.
Why not use import()? Because import() is relative to the current file, and the current file is always the Qwik framework. So QRLs have additional information that allows them to serialize imports relative to application base rather than the Qwik framework file.
|
+| [isServer](#) | | boolean | True of running on the server platform. |
+| [nextTick](#) | | (fn: () => any) => Promise<any> | Perform operation on next tick. |
+| [raf](#) | | (fn: () => any) => Promise<any> | Perform operation on next request-animation-frame. |
[Edit this section](https://github.com/BuilderIO/qwik/tree/main/packages/qwik/src/core/platform/types.ts)
diff --git a/packages/docs/src/routes/docs/(qwikcity)/routing/index.mdx b/packages/docs/src/routes/docs/(qwikcity)/routing/index.mdx
index ab7cf2d0f63..7a5fffd89a0 100644
--- a/packages/docs/src/routes/docs/(qwikcity)/routing/index.mdx
+++ b/packages/docs/src/routes/docs/(qwikcity)/routing/index.mdx
@@ -197,12 +197,12 @@ For the given example, the Qwik components will be rendered in the following ord
With Qwik, the distinction between MPA and SPA disappears; every app can be both at the same time.
The choice is no longer an architectural design determined at the beginning of the project,
- instead this decision can be made for every link.
+instead, this decision can be made for every link.
Qwik provides a `` component and `useNavigate()` hook.
These can be used to initiate an SPA refresh or navigation between pages.
-The `Link` component is the recommend way to navigate as it uses the HTML `` tag,
+The `Link` component is the recommended way to navigate as it uses the HTML `` tag,
which is the most accessible way to move between pages.
However, if you need to navigate programmatically, you can use the `useNavigate()` hook.