move to same line

Author: amirhhashemi

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

@@ -9,14 +9,11 @@ function batch<T>(fn: () => T): T
 ```
 
 `batch` is a low-level API that batches updates together.
-More precisely, `batch(fn)` holds the execution of downstream computations
-during the `fn` block, executing them all together once the block `fn` returns.
-Thus, instead of a downstream computation executing after every dependency
-update, it will update just once at the end of the batch.
+More precisely, `batch(fn)` holds the execution of downstream computations during the `fn` block, executing them all together once the block `fn` returns.
+Thus, instead of a downstream computation executing after every dependency update, it will update just once at the end of the batch.
 
 Batching improves performance by avoiding unnecessary recalculation.
-Suppose you have a downstream memo `down` that depends on
-multiple upstream signals `up1`, `up2`, and `up3`:
+Suppose you have a downstream memo `down` that depends on multiple upstream signals `up1`, `up2`, and `up3`:
 
 ```ts
 import { createSignal, createMemo, createEffect } from "solid-js"
@@ -28,17 +25,15 @@ const down = createMemo(() => up1() + up2() + up3())
 createEffect(() => console.log(down())) // outputs 6
 ```
 
-If you directly update all of the upstream signals outside of batch mode,
-then `down` will recompute every time.
+If you directly update all of the upstream signals outside of batch mode, then `down` will recompute every time.
 
 ```ts
 setUp1(4) // recomputes down, outputs 9
 setUp2(5) // recomputes down, outputs 12
 setUp3(6) // recomputes down, outputs 15
 ```
 
-If instead you update the upstream signals within a `batch`, then `down`
-will update only once at the end:
+If instead you update the upstream signals within a `batch`, then `down` will update only once at the end:
 
 ```ts
 batch(() => {
@@ -48,33 +43,21 @@ batch(() => {
 }) // recomputes down, outputs 30
 ```
 
-The impact is even more dramatic if you have *m* downstream computations
-(memos, effects, etc.) that each depends on *n* upstream signals.
-Without batching, modifying all *n* upstream signals
-would cause *m n* updates to the downstream computations.
-With batching, modifying all *n* upstream signals
-would cause *m* updates to the downstream computations.
-Given that each update takes at least *n* time
-(just to read the upstream signals), this cost savings can be significant.
-Batching is also especially helpful when the downstream effects include
-DOM updates, which can be expensive.
+The impact is even more dramatic if you have *m* downstream computations (memos, effects, etc.) that each depends on *n* upstream signals.
+Without batching, modifying all *n* upstream signals would cause *m n* updates to the downstream computations.
+With batching, modifying all *n* upstream signals would cause *m* updates to the downstream computations.
+Given that each update takes at least *n* time (just to read the upstream signals), this cost savings can be significant.
+Batching is also especially helpful when the downstream effects include DOM updates, which can be expensive.
 
-Solid uses `batch` internally to automatically batch updates for you
-in a few cases:
+Solid uses `batch` internally to automatically batch updates for you in a few cases:
 
-* Within [`createEffect`](/reference/basic-reactivity/create-effect)
-  and [`onMount`](/reference/lifecycle/on-mount)
-  (unless they are outside a [root](/reference/reactive-utilities/create-root))
-* Within the [setter of a store](/reference/store-utilities/create-store#setter)
-  (which can update several properties at once)
-* Within array methods (e.g. `Array.prototype.splice`) of a
-  [mutable store](/reference/store-utilities/create-mutable)
-  (which can update several elements at once)
+* Within [`createEffect`](/reference/basic-reactivity/create-effect) and [`onMount`](/reference/lifecycle/on-mount) (unless they are outside a [root](/reference/reactive-utilities/create-root))
+* Within the [setter of a store](/reference/store-utilities/create-store#setter) (which can update several properties at once)
+* Within array methods (e.g. `Array.prototype.splice`) of a [mutable store](/reference/store-utilities/create-mutable) (which can update several elements at once)
 
 These save you from having to use `batch` yourself in many cases.
-For the most part, automatic batching should be transparent to you,
-because accessing a signal or memo will cause it to update if it is out of date
-(as of Solid 1.4).  For example:
+For the most part, automatic batching should be transparent to you, because accessing a signal or memo will cause it to update if it is out of date (as of Solid 1.4).
+For example:
 
 ```ts
 batch(() => {
@@ -88,9 +71,6 @@ batch(() => {
 }) // recomputes down, outputs 36
 ```
 
-You can think of `batch(fn)` as setting a global "batch mode" variable,
-calling the function `fn`, and then restoring the global variable to its
-previous value.
+You can think of `batch(fn)` as setting a global "batch mode" variable, calling the function `fn`, and then restoring the global variable to its previous value.
 This means that you can nest `batch` calls, and they will form one big batch.
-It also means that, if `fn` is asynchronous,
-only the updates before the first `await` will be batched.
+It also means that, if `fn` is asynchronous, only the updates before the first `await` will be batched.