add information about createEffect at top level, eagerly accessing si…

…gnals in batch, and reference to batch from create-effect

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

@@ -40,7 +40,9 @@ createEffect((prevA) => {
 // ^ the initial value of the effect is 0
 ```
 
-Effects are meant primarily for side effects that read but don't write to the reactive system: it's best to avoid setting signals in effects, which without care can cause additional rendering or even infinite effect loops. Instead, prefer using [createMemo](/reference/basic-reactivity/create-memo) to compute new values that depend on other reactive values, so the reactive system knows what depends on what, and can optimize accordingly.
+Effects are meant primarily for side effects that read but don't write to the reactive system: it's best to avoid setting signals in effects, which without care can cause additional rendering or even infinite effect loops.
+Instead, prefer using [createMemo](/reference/basic-reactivity/create-memo) to compute new values that depend on other reactive values, so the reactive system knows what depends on what, and can optimize accordingly.
+However, if signals are set in an effect, computations subscribed to that signal will be executed only once the effect completes (see [batch](/reference/reactive-utilities/batch) for more detail).
 
 The first execution of the effect function is not immediate; it's scheduled to run after the current rendering phase (e.g., after calling the function passed to [render](/reference/rendering/render), [createRoot](/reference/reactive-utilities/create-root), or [runWithOwner](/reference/reactive-utilities/run-with-owner)).
 If you want to wait for the first execution to occur, use [queueMicrotask](https://developer.mozilla.org/en-US/docs/Web/API/queueMicrotask) (which runs before the browser renders the DOM) or `await Promise.resolve()` or `setTimeout(..., 0)` (which runs after browser rendering).

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

@@ -8,5 +8,7 @@ function batch<T>(fn: () => T): T;
 
 This is a low level API that is used by Solid to batch updates.
 It holds executing downstream computations within the block until the end to prevent unnecessary recalculation.
-Solid Store's set method, Mutable Store's array methods, and Effects automatically wrap their code in a batch.
-This is useful for when you want to batch a set of computations that are not wrapped in a batch already.
+Although the computations listening for changes to the signal are not yet notified, accessing the value of a signal set within the batch will still return the updated value (in Solid versions >=1.4).
+
+Solid Store's set method, Mutable Store's array methods, and Effects (unless it is defined outside a root) automatically wrap their code in a batch.
+This is useful in user-land for when you want to batch a set of computations that are not wrapped in a batch already.