Fix grammar and typos (#953)

Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>
Co-authored-by: Sarah <[email protected]>
Co-authored-by: Atila Fassina <[email protected]>
Co-authored-by: Erik Demaine <[email protected]>

Author: 5 people

src/routes/concepts/refs.mdx

@@ -29,7 +29,7 @@ function Component() {
 This lets you create and access DOM elements similar to [`document.createElement`](https://developer.mozilla.org/en-US/docs/Web/API/Document/createElement) but without having to wait until it is attached to the DOM. 
 It can be used multiple times without having to worry about duplicate selectors.
 
-The downside to this approach is it separates the element and any child elements from the rest of the JSX structure. 
+The downside of this approach is that it separates the element and any child elements from the rest of the JSX structure. 
 This makes the component's JSX structure more difficult to read and understand.
 
 ## Refs in Solid

src/routes/reference/basic-reactivity/create-resource.mdx

@@ -97,7 +97,7 @@ You can now check whether a Resource is `unresolved`, `pending`, `ready`, `refre
 | `refreshing` | Yes            | Yes     | No        |
 | `error`      | No             | No      | Yes       |
 
-2. When server rendering resources especially when fetching when embedding Solid in other system that fetch before render, you might want to initiate the resource with this prefetched value instead of fetching again and having the resource serialize it in it's own state.
+2. When server-rendering resources, especially when embedding Solid in other systems that fetch data before rendering, you might want to initialize the resource with this prefetched value instead of fetching again and having the resource serialize it in its own state.
 You can use the new `ssrLoadFrom` option for this. 
 Instead of using the default `server` value, you can pass `initial` and the resource will use `initialValue` as if it were the result of the first fetch for both SSR and hydration.
 

src/routes/reference/basic-reactivity/create-signal.mdx

@@ -3,7 +3,7 @@ title: createSignal
 ---
 
 Signals are the most basic reactive primitive. 
-They track a single value (which can be any JavaScript object) that changes over time.
+They track a single value (which can be a value of any type) that changes over time.
 
 ```tsx
 import { createSignal } from "solid-js"
@@ -39,7 +39,7 @@ Calling the getter (e.g., `count()` or `ready()`) returns the current value of t
 Crucial to automatic dependency tracking, calling the getter within a tracking scope causes the calling function to depend on this Signal, so that function will rerun if the Signal gets updated.
 
 Calling the setter (e.g., `setCount(nextCount)` or `setReady(nextReady)`) sets the Signal's value and updates the Signal (triggering dependents to rerun) if the value actually changed (see details below). 
-The setter takes either the new value for the signal or a function that maps the last value of the signal to a new value as its only argument. 
+The setter takes either the new value for the signal or a function that maps the previous value of the signal to a new value as its only argument. 
 The updated value is also returned by the setter. As an example:
 
 ```tsx
@@ -102,7 +102,7 @@ const [count, setCount] = createSignal(0, {
 })
 ```
 
-Here's are some examples of this option in use:
+Here are some examples of this option in use:
 
 ```tsx
 // use { equals: false } to allow modifying object in-place;
@@ -115,7 +115,7 @@ setObject((current) => {
 	return current
 })
 
-// use { equals: false } signal as trigger without value:
+// use { equals: false } to create a signal that acts as a trigger without storing a value:
 const [depend, rerun] = createSignal(undefined, { equals: false })
 // now calling depend() in a tracking scope
 // makes that scope rerun whenever rerun() gets called

src/routes/reference/component-apis/children.mdx

@@ -10,9 +10,9 @@ function children(fn: () => JSX.Element): () => ResolvedChildren
 
 ```
 
-The children's helper is used for more complex interactions with props. 
-When you're not just passing children to another component using props.children once in JSX, you should use children. 
-Props are normally passed in via a getter for props.children in this manner:
+The `children` helper is used for more complex interactions with props. 
+When you're not just passing children to another component using `props.children` once in JSX, you should use `children`. 
+Props are normally passed in via a getter for `props.children` in this manner:
 
 ```tsx
 const resolved = children(() => props.children)
@@ -57,7 +57,7 @@ const resolved = children(() => props.children)
 return <Show when={visible()}>{resolved()}</Show>
 ```
 
-To evaluate the children only when `<Show>` would render them, you can push the call to children inside a component or a function within `<Show>`, which only evaluates its children when the when condition is true. 
+To evaluate the children only when `<Show>` would render them, you can push the call to children inside a component or a function within `<Show>`, which only evaluates its children when `when` condition is true. 
 Another nice workaround is to pass `props.children` to the children helper only when you actually want to evaluate the children:
 
 ```tsx

src/routes/reference/component-apis/create-context.mdx

@@ -7,7 +7,7 @@ order: 5
 Context provides a form of dependency injection in Solid. 
 It is used to save from needing to pass data as props through intermediate components (aka** prop drilling**).
 This function creates a new context object that can be used with [useContext](/reference/component-apis/use-context) and offers the Provider control flow.
-Default Context is used when no Provider is found above in the hierarchy.
+The default value is used when no Provider is found above in the hierarchy.
 
 ## Usage
 

src/routes/reference/components/show.mdx

@@ -3,7 +3,7 @@ title: <Show>
 order: 5
 ---
 
-The Show control flow is used to conditional render part of the view: it renders children when the when is truthy, a fallback otherwise. It is similar to the ternary operator `(when ? children : fallback)` but is ideal for templating JSX.
+The `Show` control flow is used to conditionally render part of the view: it renders children when `when` is truthy, a fallback otherwise. It is similar to the ternary operator `(when ? children : fallback)` but is ideal for templating JSX.
 
 ```ts
 import { Show } from "solid-js"
@@ -17,23 +17,23 @@ function Show<T>(props: {
 }): () => JSX.Element
 ```
 
-Here's an example of using the Show control flow:
+Here's an example of using the `Show` control flow:
 
 ```tsx
 <Show when={state.count > 0} fallback={<div>Loading...</div>}>
 	<div>My Content</div>
 </Show>
 ```
 
-Show can also be used as a way of keying blocks to a specific data model. For example the function is re-executed whenever the user model is replaced.
+`Show` can also be used as a way of keying blocks to a specific data model. For example the function is re-executed whenever the user model is replaced.
 
 ```tsx
 <Show when={state.user} fallback={<div>Loading...</div>} keyed>
 	{(user) => <div>{user.firstName}</div>}
 </Show>
 ```
 
-If the `keyed` property is not used, the argument of a child function will be an accessor containing the item.
+If the `keyed` property is not used, the argument of the child function will be an accessor containing the item.
 
 ```tsx
 <Show when={state.user} fallback={<div>Loading...</div>}>
@@ -47,4 +47,4 @@ If the `keyed` property is not used, the argument of a child function will be an
 | :--------- | :-------------------------------- | :-------------------------------------------- |
 | `when`     | `T \| undefined \| null \| false` | The value to test for truthiness              |
 | `keyed`    | `boolean`                         | Whether to key the block to the value of when |
-| `fallback` | `JSX.Element`                     | The fallback to render when when is falsy     |
+| `fallback` | `JSX.Element`                     | The fallback to render when the `when` is falsy     |

src/routes/reference/components/suspense.mdx

@@ -3,7 +3,7 @@ title: <Suspense>
 order: 5
 ---
 
-A component that tracks all resources read under it and shows a fallback placeholder state until they are resolved. What makes `Suspense` different than `Show` is it is non-blocking in that both branches exist at the same time even if not currently in the DOM. This means that the fallback can be rendered while the children are loading. This is useful for loading states and other asynchronous operations.
+A component that tracks all resources read under it and shows a fallback placeholder state until they are resolved. What makes `Suspense` different than `Show` is that it is non-blocking in the sense that both branches exist at the same time even if not currently in the DOM. This means that the fallback can be rendered while the children are loading. This is useful for loading states and other asynchronous operations.
 
 ```tsx
 import { Suspense } from "solid-js"
@@ -30,7 +30,7 @@ Here's an example of a `Suspense` component that shows a loading spinner while t
 `<Suspense>` is triggered whenever a resource is read under the suspense boundary, and waits until all resources read
 under the suspense boundary have resolved. Often, however, you may not want this behavior. For example, if your entire page is
 wrapped in suspense, you may not want a resource that only populates a certain part of the page to trigger suspense.
-In that case, you can wrap that resource usage its own suspense boundary, and the resource will only trigger the
+In that case, you can wrap that resource usage in its own suspense boundary, and the resource will only trigger the
 closest suspense boundary.
 
 For example, in the code below, only the `title()` resource will trigger the top level suspense boundary, and only the `data()`
@@ -52,7 +52,7 @@ const MyComponent = () => {
 
 ## The purpose of {"<Suspense>"}
 
-To understand the purpose of suspense, let's consider the following code snippets. These snippets will have some drawbacks which we will solve by using suspense. We will also see how it is possible to use suspense yet not reap its benefits.
+To understand the purpose of suspense, let's consider the following code snippets. These snippets will have some drawbacks which we will solve by using suspense. We will also see how it is possible to use `Suspense` yet not reap its benefits.
 
 Our example use case is to display a user profile. A naive snippet would look like this:
 
@@ -112,7 +112,7 @@ const MyComponentWithSuspense = () => {
 
 In this case, the `div`s are created immediately, but instead of being attached to the document body, the fallback is shown. Once the resource resolves, the text in the `div`s is updated, and then they are attached to the document (and the fallback removed).
 
-It is important to note that _execution of the component does not pause_ when using suspense. Instead, when a resource is read under a suspense boundary, it ensures that the nodes are not attached to the document until after the resource has resolved. Suspense allows us to have the best of both worlds: do as much work as we can _before_ the resource resolves, and also show a fallback until then.
+It is important to note that _the execution of the component does not pause_ when using suspense. Instead, when a resource is read under a suspense boundary, it ensures that the nodes are not attached to the document until after the resource has resolved. Suspense allows us to have the best of both worlds: do as much work as we can _before_ the resource resolves, and also show a fallback until then.
 
 With this in mind, we can understand that there isn't much gained from suspense in the following code:
 

src/routes/reference/jsx-attributes/ref.mdx

@@ -9,12 +9,12 @@ Refs are a way of getting access to underlying DOM elements in our JSX. While it
 // variable assigned directly by ref
 let myDiv;
 
-// use onMount or createEffect to read after connected to DOM
+// use onMount or createEffect to read after connected to the DOM
 onMount(() => console.log(myDiv));
 
 <div ref={myDiv} />
 
-// Or, callback function (called before connected to DOM)
+// Or, callback function (called before connected to the DOM)
 <div ref={el => console.log(el)} />
 ```
 

src/routes/reference/reactive-utilities/from.mdx

@@ -24,7 +24,7 @@ This basically turns any subscribable (object with a subscribe method) into a Si
 const signal = from(obsv$)
 ```
 
-It can also take a custom producer function where the function is passed a setter function that returns a unsubscribe function:
+It can also take a custom producer function where the function is passed a setter function that returns an unsubscribe function:
 
 ```tsx
 const clock = from((set) => {

src/routes/reference/reactive-utilities/run-with-owner.mdx

@@ -19,7 +19,7 @@ Having a (correct) owner is important for two reasons:
 - Computations without an owner cannot be cleaned up. 
 For example, if you call `createEffect` without an owner (e.g., in the global scope), the effect will continue running forever, instead of being disposed when its owner gets disposed.
 
-- useContext obtains context by walking up the owner tree to find the nearest ancestor providing the desired context. 
+- `useContext` obtains context by walking up the owner tree to find the nearest ancestor providing the desired context. 
 So without an owner you cannot look up any provided context (and with the wrong owner, you might obtain the wrong context).
 
 Manually setting the owner is especially helpful when doing reactivity outside of any owner scope.