Docs: Update sharing state example

[marvinhagemeister]

We shouldn't encourage the use of global signals here:

https://fresh.deno.dev/docs/examples/sharing-state-between-islands#independent-islands

[king8fisher]

Enhance explanation on how a global signal can lead to a leak of the state between several sessions.

Potentially, provide a link to https://shared-signal.deno.dev/ example and ask users to try to open it in several different browsers. Explain how such kind of a signal is shared across requests. Explain what will happen eventually if no one requests the link for some time. Quoting @marvinhagemeister, "A serverless function doesn't ensure request isolation. It just means that you have a short-lived server that will be killed when no requests come in. For as long as requests are coming in they'll still hit the same isolate and it would a bit wasteful to always destroy the instance and re-create it from scratch for every request."

import { signal } from "https://esm.sh/@preact/signals-core";

const sig = signal (0)

Deno.serve((_req: Request) => {
  sig.value = sig.peek() + 1
  return new Response("Hello World: " + sig.value);
});

Provide a warning to the current examples of a shared state given at:
https://fresh.deno.dev/docs/examples/sharing-state-between-islands

Provide an example of a solution that wouldn't be "leaking" the state.

Use some of the wordings given by Marvin:
"Think of it this way: Signals are merely a mechanism to make values depend on other values and trigger updates when the subscribed signal changes. By default Fresh only runs code on the server. Any signals you use in routes will only never be sent to the browser. At this stage the browser is completely unaware of any signals.

Now we introduce islands into the mix. The code for islands is bundled and served to the browser. Anything you do in JS inside an island will be run in the browser. So if we create a signal inside an island it will re-render a component if you listen to it.

Now sometimes you want to share data from your route to your island. Often you even want to islands to depend on the same state and be updated when the original value changes. This is where signals come in again. When you pass a signal to an island as a prop, Fresh will see that and think "hey it's probably important that I send this signal to the browser". So Fresh serializes the signal, sends it to the browser, and upon booting the page the signal is re-created in the browser. At that point the connection from the signal to the server is severed and doesn't exist anymore. It's now a signal that only lives inside the browser. Behind the scenes we just copy the value from the server and create a new signal on the client. Once we re-created that in the browser we pass it to the island as a prop.

So overall it's not a matter of where you export a signal, but rather how you use it"

[king8fisher]

Potentially update https://fresh-with-signals.deno.dev as well.

[bartlomieju]

Fixed in #3712 — the cart example has been rewritten to create signals per-render inside the route component and pass them as props, instead of using module-level globals. Also added a warning about why module-level signals are dangerous on the server.