docs: site cleanup

nathan-brown-omc · daKmoR · commit 1cd95083840d · 2022-09-10T10:34:13.000+02:00
Remove extraneous words and correct misphrasings.
diff --git a/site/pages/10--docs/10--setup/10--getting-started.rocket.md b/site/pages/10--docs/10--setup/10--getting-started.rocket.md
@@ -93,4 +93,4 @@ If something is missing in the documentation or if you found some part confusing
 
 ## Credit
 
-This getting started guide was originally based off of [astro](https://astro.build/) getting started guide.
+This getting started guide was originally based off the [astro](https://astro.build/) getting started guide.
diff --git a/site/pages/10--docs/10--setup/20--adding-pages.rocket.md b/site/pages/10--docs/10--setup/20--adding-pages.rocket.md
@@ -44,11 +44,11 @@ Before we get started we need to engage the engines via
 npm start
 ```
 
-This with start rocket in development mode and you will see your site running in your browser.
+This will start rocket in development mode and you will see your site running in your browser.
 
 ## What is a page?
 
-A page is a file that ends either with `*.rocket.js`, `*.rocket.md` or `*.rocket.html` and is located in the input directory (`site/pages` by default). Pages will make up the majority or your website.
+A page is a file that ends either with `*.rocket.js`, `*.rocket.md` or `*.rocket.html` and is located in the input directory (`site/pages` by default). Pages will make up the majority of your website.
 
 The simplest way to get started is to create a file
 
diff --git a/site/pages/10--docs/20--basics/10--project-structure.rocket.md b/site/pages/10--docs/20--basics/10--project-structure.rocket.md
@@ -53,7 +53,7 @@ e.g.
 
 ## Recommended Project Structure
 
-Even if there is no enforce project structure it still makes sense to follow some common best practices.
+Even if there is no enforced project structure it still makes sense to follow some common best practices.
 
 - `site/pages/*` - All the pages of your website (e.g. all `*.rocket.{js,md,html}` files)
 - `site/pages/about/_assets/*` - Keep assets related to pages close to the page itself (e.g. images, videos, ...)
@@ -116,4 +116,4 @@ Rocket has complete control over how these files get processed, optimized, and b
 
 For most users, the majority of your files will live inside of the `site/pages/` and `site/src/` directory so that Rocket can optimize them in your final build. By contrast, the `site/public/` directory is the place for any files to live outside of the Rocket build process.
 
-If you put a file into the public folder, it will not be processed by Rocket. Instead it will be copied into the build folder untouched. This can be useful for specific file like `robots.txt` or `site.webmanifest` or sometimes for assets like images that you need in a specific location.
+If you put a file into the public folder, it will not be processed by Rocket. Instead it will be copied into the build folder untouched. This can be useful for specific files like `robots.txt` or `site.webmanifest` or sometimes for assets like images that you need in a specific location.
diff --git a/site/pages/10--docs/20--basics/20--pages.rocket.md b/site/pages/10--docs/20--basics/20--pages.rocket.md
@@ -30,19 +30,19 @@ export const description = `An intro to Rocket pages, which is the actual websit
 
 # Pages
 
-**Pages** are a the only files that get rendered into the output folder.
+**Pages** are the only files that get rendered into the output folder.
 
 3 types of pages are supported:
 
 - `*.rocket.md` - A page with markdown content.
 - `*.rocket.html` - A page with HTML content.
 - `*.rocket.js` - A page with JavaScript content.
 
-Feel free to choose a format for each pages that best suits its content.
+Feel free to choose a format for each page that best suits its content.
 
 ## File-based Routing
 
-Rockets uses Pages to do something called **file-based routing.** Every file in your `pages` directory becomes a page on your site, using the file name to decide the final route.
+Rocket uses Pages to do something called **file-based routing.** Every file in your `pages` directory becomes a page on your site, using the file name to decide the final route.
 
 ```
 site/pages/index.rocket.md        -> mysite.com/
@@ -72,7 +72,7 @@ export default () => `
 
 👆 This is the JavaScript version which all other formats automatically convert to.
 
-However for you your convenience you can also write your page in HTML and it will be automatically converted into the JavaScript version above.
+However for your convenience you can also write your page in HTML and it will be automatically converted into the JavaScript version above.
 
 👉 `site/pages/index.rocket.html`
 
@@ -104,8 +104,8 @@ Or you can write markdown.
 
 Markdown and HTML files are automatically converted to their JavaScript equivalents.
 That is also how they get their template literal super powers.
-Those converted files only life for a fraction of a second and are deleted after the page is done rendering.
-If you would like to keep them for debugging or out of curiosity you can export the following flag to prefect the cleanup.
+Those converted files only live for a fraction of a second and are deleted after the page is done rendering.
+If you would like to keep them for debugging or out of curiosity you can export the following flag to prevent the cleanup.
 
 ```js
 export const keepConvertedFiles = true;
diff --git a/site/pages/10--docs/20--basics/30--data-cascade.rocket.md b/site/pages/10--docs/20--basics/30--data-cascade.rocket.md
@@ -90,7 +90,7 @@ For that reasons you can override the layout via exporting `layout` on a specifi
 
 In the above example we have 4 layouts we define in different places.
 
-1. Default layout use by all pages unless overwritten in `recursive.data.js`
+1. Default layout used by all pages unless overwritten in `recursive.data.js`
 2. Explicitly specifying a layout `index.rocket.js`
 3. use `blog/local.data.js` to set a layout for all pages in `blog`
 4. use `docs/codelabs/local.data.js` to set a layout for all pages in `codelabs`
diff --git a/site/pages/10--docs/20--basics/40--components.rocket.md b/site/pages/10--docs/20--basics/40--components.rocket.md
@@ -28,11 +28,11 @@ export const needsLoader = true;
 
 # Components
 
-Components in Rocket are the "just" the web standard [web components](https://developer.mozilla.org/en-US/docs/Web/Web_Components). They are used to create reusable components that can be used in any web page.
+Components in Rocket are "just" the web standard [web components](https://developer.mozilla.org/en-US/docs/Web/Web_Components). They are used to create reusable components that can be used in any web page.
 
 <inline-notification>
 
-Web component only live within the html body. For content within the head or a full html page please see [layouts](./50--layouts.rocket.md).
+Web components only live within the html body. For content within the head or a full html page please see [layouts](./50--layouts.rocket.md).
 
 </inline-notification>
 
@@ -84,7 +84,7 @@ We can now put this code in Rocket JavaScript, Markdown or Html pages.
 <rocket-greeting>Go</rocket-greeting>
 ````
 
-will result a server rendered output that does not load ANY JavaScript
+will result in a server rendered output that does not load ANY JavaScript
 
 ```
 Hello World
@@ -124,7 +124,7 @@ Note the empty lines between html & markdown. They are necessary as this is how
 
 ## Manually Loading Components
 
-We can define as many components as we want within a page but typically it's best to define them in a separate files.
+We can define as many components as we want within a page but typically it's best to define them in separate files.
 
 So we will move our component code into a new file 👉 `/site/src/components/rocket-greeting.js`
 
@@ -257,8 +257,8 @@ export const components = {
 
 ### Hydration
 
-Component that do not have any interactivity will never need to be hydrated so they may be imported statically on the server side.
-All other component should be handled via the `components` object to enable handling of loading and registration.
+Components that do not have any interactivity will never need to be hydrated so they may be imported statically on the server side.
+All other components should be handled via the `components` object to enable handling of loading and registration.
 
 Doing so enables hydration based on attributes on the component.
 
diff --git a/site/pages/10--docs/20--basics/50--layouts.rocket.md b/site/pages/10--docs/20--basics/50--layouts.rocket.md
@@ -28,7 +28,7 @@ export const needsLoader = true;
 
 # Layouts
 
-Layout are special in that sense that they output the full html page (including html, head, body, etc).
+Layouts are special in the sense that they output the full html page (including html, head, body, etc).
 
 The simplest layout you can make is
 
@@ -48,7 +48,7 @@ export const layout = data => html`
 `;
 ```
 
-and that will work fine however now every page will have the same `title` in the head.
+and that will work fine, however, now every page will have the same `title` in the head.
 
 If we now have the following markdown file:
 
@@ -95,7 +95,7 @@ For more details see the following [lit issue](https://github.com/lit/lit/issues
 
 </inline-notification>
 
-In order to provide this `data.title` we now need to export is within the page.
+In order to provide this `data.title` we now need to export it within the page.
 The code could look something like this.
 
 ````md
@@ -151,7 +151,7 @@ const layoutB =
 
 <inline-notification type="warning">
 
-Partial html is not supported in [lit](http://lit.dev) as it uses the browser build in html parser which try to "auto correct" your html by closing tags.
+Partial html is not supported in [lit](http://lit.dev) as it uses the browser build in html parser which trys to "auto correct" your html by closing tags.
 e.g. this
 
 <!-- prettier-ignore-start -->
diff --git a/site/pages/10--docs/20--basics/60--routing.rocket.md b/site/pages/10--docs/20--basics/60--routing.rocket.md
@@ -30,7 +30,7 @@ Rocket uses **file-based routing** to generate your build URLs based on the file
 
 ## Static routes
 
-Rocket Pages are Markdown (`rocket.md`), HTML (`rocket.html`) and JavaScript (`rocket.js`) in the `site/pages` directory become pages on your website. Each page’s route is decided based on its filename and path within the `site/pages` directory. This means that there is no separate "routing config" to maintain in an Rocket project.
+Rocket Pages are Markdown (`rocket.md`), HTML (`rocket.html`) and JavaScript (`rocket.js`) in the `site/pages` directory become pages on your website. Each page’s route is decided based on its filename and path within the `site/pages` directory. This means that there is no separate "routing config" to maintain in a Rocket project.
 
 ```bash
 # Example: Static routes
diff --git a/site/pages/10--docs/20--basics/70--navigation.rocket.md b/site/pages/10--docs/20--basics/70--navigation.rocket.md
@@ -76,7 +76,7 @@ This will result in something like this:
 </nav>
 ```
 
-Rocket comes with multiple build in menus you can see [below](#menu-types).
+Rocket comes with multiple built-in menus you can see [below](#menu-types).
 
 ## Menu Data
 
@@ -107,11 +107,11 @@ Now the menu will be called "Docs".
 Within a menu the text of the links is defined by the following priority:
 
 1. menuLinkText => `export const menuLinkText = 'Page Title In Menu';`
-2. h1 => first `<h1>` in the page)
+2. h1 => first `<h1>` in the page
 3. title => html title tag
 4. sourceRelativeFilePath => fallback if no other option is available
 
-You can influence that data that gets provided to the menu by setting exports.
+You can influence the data that gets provided to the menu by setting exports.
 
 ### link-text="..."
 
@@ -168,7 +168,7 @@ Sometimes there is a need to completely exclude a page from the pageTree.
 Pages with this flag will not exist at all in the pageTree - therefore you will not be able to access them for "anything" not even in a sitemap or an update feed.
 Pages that have sub pages can NOT use this flag as it would mean those sub pages would not have a parent page.
 
-Typical use case are utility pages that are not meant to be accessed by typical users.
+Typical use cases are utility pages that are not meant to be accessed by typical users.
 
 ```js
 export const menuExclude = true;
@@ -245,7 +245,7 @@ In case you want to take full control over the order you can apply the following
    - The menu order and file system order will no longer match
    - But no numbers in folder / filenames
 
-3. Instantiate a new PageTree and providing your own `modelComparatorFn`
+3. Instantiate a new PageTree and provide your own `modelComparatorFn`
 
    ```js
    function modelComparatorFn(a, b) {
@@ -261,7 +261,7 @@ In case you want to take full control over the order you can apply the following
 
 ## Page Tree
 
-The data of the page tree gets saves as a JSON file in the root of the `pages` directory.
+The data of the page tree gets saved as a JSON file in the root of the `pages` directory.
 
 It typically looks something like this:
 
@@ -440,7 +440,7 @@ import {
 5. **NextMenu**
 
    - shows the next page in the tree
-   - is either the first child or he next sibling
+   - is either the first child or the next sibling
 
    ```html
    <web-menu name="next">
diff --git a/site/pages/10--docs/20--basics/80--hydration.rocket.md b/site/pages/10--docs/20--basics/80--hydration.rocket.md
@@ -31,7 +31,7 @@ export const needsLoader = true;
 # Hydration
 
 By default all components are only rendered on the server.
-This however means those components are "static" and can not add interactivity.
+However, this means those components are "static" and can not add interactivity.
 
 To add interactivity to your component you can either render it only on the client or you can render on the server and `hydrate` it on the client.
 
@@ -69,9 +69,9 @@ The automatic loading/hydration only works if you [register components to the ro
 
 ## Server Loading
 
-Server Loading has almost zero impact on the client side page performance and is therefore fastest possible solution available.
+Server Loading has almost zero impact on the client side page performance and is therefore the fastest possible solution available.
 
-Loading and rendering on the server is the default and for that reasons does not need to be specified.
+Loading and rendering on the server is the default and for that reason does not need to be specified.
 
 ```html
 <blog-header></blog-header>
@@ -263,7 +263,7 @@ Results in `server rendering` of all `my-component`s.
 Why theses impacts?
 
 1. client - if you eagerly load & render the component on the client then bloating the html of some components by server rendering does not bring any benefit
-2. hydrate - hydration means that all component with the same tag name will be hydrated on the client - you can not keep a server only variation of a component
+2. hydrate - hydration means that all components with the same tag name will be hydrated on the client - you can not keep a server only variation of a component
 3. server - almost zero client side impact
 
 <inline-notification>
diff --git a/site/pages/10--docs/20--basics/90--assets.rocket.md b/site/pages/10--docs/20--basics/90--assets.rocket.md
@@ -103,7 +103,7 @@ If your package is `"type": "module"` then you can also add exports.
 }
 ```
 
-Once you have an export it also enables to "self" reference your package.
+Once you have an export it also enables you to "self" reference your package.
 Combine this with the `:resolve` function means that you can reference assets always with the same path.
 Completely unrelated to the path of the file itself.
 
diff --git a/site/pages/10--docs/20--basics/95--configuration.rocket.md b/site/pages/10--docs/20--basics/95--configuration.rocket.md
@@ -54,7 +54,7 @@ For settings that may be overridden within a page, use the [**data cascade**](./
 
 </inline-notification>
 
-Rocket is primarily build around plugins for each of its systems.
+Rocket is primarily built around plugins for each of its systems.
 
 Given that rocket comes with a list of default plugins and that presets can add plugins it's very important to not "just" set a new "plugins" property.
 
@@ -65,7 +65,7 @@ New plugins can be added and all default plugins can be adjusted or even removed
 ```js
 /** @type {import('rocket/cli').RocketCliConfig} */
 export default {
-  // add a rollup plugins to the web dev server (will be wrapped with @web/dev-server-rollup) AND the rollup build (e.g. enable json importing)
+  // add a rollup plugin to the web dev server (will be wrapped with @web/dev-server-rollup) AND the rollup build (e.g. enable json importing)
   setupDevServerAndBuildPlugins: [],
 
   // add a plugin to the web dev server (will not be wrapped) (e.g. esbuild for TypeScript)
@@ -139,7 +139,7 @@ For some projects you might want to enable non-standard behaviors like importing
 import data from './data.json';
 ```
 
-You can accomplish this with Rollup and dev server plugins. Make sure to add both the dev-server plugin as well as the Rollup plugin, so that the behaviors is the same during development as it is in the production build.
+You can accomplish this with Rollup and dev server plugins. Make sure to add both the dev-server plugin as well as the Rollup plugin, so that the behavior is the same during development as it is in the production build.
 
 For these cases you can use `setupDevServerAndBuildPlugins`, which will automatically add the plugin for you to both Rollup and dev-server:
 
@@ -186,7 +186,7 @@ export default /** @type {import('rocket/cli').RocketCliOptions} */ ({
 
 ### BuildOptions (rollup)
 
-For example if you wanna add an `acron` plugin to rollup
+For example if you wanna add an `acorn` plugin to rollup
 
 ```js
 import { importAssertions } from 'acorn-import-assertions';
diff --git a/site/pages/10--docs/30--guides/20--social-media.rocket.md b/site/pages/10--docs/30--guides/20--social-media.rocket.md
@@ -34,7 +34,7 @@ export const subTitle =
 Having a nice preview image for social media can be very helpful.
 For that reason Rocket has a specific functionality to generate a preview image.
 
-This functionality is disable by default. You can enable it by exporting a `openGraphLayout` function/class instance.
+This functionality is disabled by default. You can enable it by exporting a `openGraphLayout` function/class instance.
 
 The functionality is the same as normal [Layouts](../20--basics/50--layouts.rocket.md).
 
@@ -53,7 +53,7 @@ The functionality is the same as normal [Layouts](../20--basics/50--layouts.rock
    site/pages/sitemap.xml.rocket.js  -> open graph only happens for html files
    ```
 
-2. During the the build phase is does the following steps
+2. During the build phase it does the following steps
 3. If there is a `filename.opengraph.html` file it will open that file in puppeteer
 4. It sets its screen size to 1200×628px and takes a screenshot with DPR or 2 (e.g. the image will have 2400x1228px)
 5. Adjusts the "output file" e.g. `index.html` by injecting
@@ -66,13 +66,13 @@ The functionality is the same as normal [Layouts](../20--basics/50--layouts.rock
 
    if no `<meta property="og:image"` is present
 
-6. deletes the `filename.opengraph.html` file
+6. Deletes the `filename.opengraph.html` file
 
 ## How to use it
 
 Add an `openGraphLayout` export to our page.
 
-Generally it's probably bet if we put this in our root `recursive.data.js` file which means that every page will have this functionality.
+Generally it's probably best if we put this in our root `recursive.data.js` file which means that every page will have this functionality.
 If a certain page needs a different layout we can override it.
 
 👉 `recursive.data.js`
@@ -244,7 +244,7 @@ export const subTitle = 'From zero to hero';
 
 ## Creating an Overview
 
-Once you have defined an openGraphLayout for all you pages it makes sense to check them.
+Once you have defined an openGraphLayout for all your pages it makes sense to check them.
 This however can be a time consuming process.
 
 So it makes sense to use an overview over all the open graph images we will have.
@@ -312,7 +312,7 @@ export const layout = data => html`
 `;
 ```
 
-There is quite some much in there so let's go though the code.
+There is quite a lot in there so let's go though the code.
 
 ```js
 import { pageTree } from '#src/layouts/layoutData.js';
diff --git a/site/pages/10--docs/30--guides/30--images.rocket.md b/site/pages/10--docs/30--guides/30--images.rocket.md
diff --git a/site/pages/10--docs/30--guides/80--web-fonts.rocket.md b/site/pages/10--docs/30--guides/80--web-fonts.rocket.md
diff --git a/site/pages/20--presets/20--launch/10--overview.rocket.md b/site/pages/20--presets/20--launch/10--overview.rocket.md
diff --git a/site/pages/20--presets/20--launch/20--service-worker.rocket.md b/site/pages/20--presets/20--launch/20--service-worker.rocket.md

Original file line number	Diff line number	Diff line change
`@@ -93,4 +93,4 @@ If something is missing in the documentation or if you found some part confusing`
`93`	`93`
`94`	`94`	`## Credit`
`95`	`95`
`96`		`-This getting started guide was originally based off of [astro](https://astro.build/) getting started guide.`
	`96`	`+This getting started guide was originally based off the [astro](https://astro.build/) getting started guide.`