Add some more details about batch

[mosheduminer]

This PR is the follow up from a conversation in the discord, where someone tested the behavior of createEffect and found it wasn't batched. This PR addresses the confusion by documenting when createEffect is automatically batched, and when it isn't. It also adds another piece of information I felt was missing from the batch docs, namely the expected behavior when setting and then accessing a signal within a batch. This behavior used to be different pre-v1.4 which makes it additionally useful as a documentation of a breaking change.

In summary, this PR clarifies:

• createEffect is not batched outside root / at top level
• the expected behavior when eagerly accessing signals set within the same batch (prior to v1.4 this returned the old value, this is not longer the case)

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[netlify]

✅ Deploy Preview for solid-docs ready!

Name	Link
🔨 Latest commit	de39208
🔍 Latest deploy log	https://app.netlify.com/sites/solid-docs/deploys/6637a4d57c1863000848e5f3
😎 Deploy Preview	https://deploy-preview-592--solid-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[titoBouzout]

Please hold this PR we are still trying to clarify some points that may or may not lead to some small change.

[LadyBluenotes]

If it's not ready for review, please put it as a draft!

[atilafassina]

Please hold this PR we are still trying to clarify some points that may or may not lead to some small change.

hey @titoBouzout , I lost track of this convo. What came out of it?

[titoBouzout]

hey @titoBouzout , I lost track of this convo. What came out of it?

Top level effects aren't batched, regular effects are batched. The idea was to batch them all to make them consistent. While the change is welcome solidjs/solid#2107 this probably will take effect on solid 2.0 to avoid unnecessary behavior changes, which sounds like a sensible option and this pr could probably be reviewed I guess

[brenelz]

Is this PR still valid?

[mosheduminer]

Looks like I dropped the ball on this one, I'll add the distinction between top level and component level and reopen it.

[edemaine]

Note that some of this is getting addressed in #982, so perhaps best to wait for that to land first.

[mosheduminer]

@edemaine sure.

[edemaine]

@mosheduminer I ended up having to fix some bugs in #982, so while I was at it, I tried to incorporate your changes into that PR (with commit coauthor credit). Do you want to take a look (last two commits) and confirm that it looks good to you? If so, I think we can merge that PR and close this PR.

[mosheduminer]

@edemaine thanks! Looks good, except the behavior (introduced in 1.4) of returning the non-stale value is true for both signals and memos (both used), but your edit only mentions memos. I think it might be worthwhile to document the behavior as introduced for signals well, mainly so people looking can see that prior to 1.4 the behavior of signals was different.

[edemaine]

Good idea! Done.