State sharing between islands

[nemtsov]

Hi there! What's the recommended way to share state between islands? One simple use-case (extending the base example) is if I'd like to have two Counters which share the same count, and you can increase or decrease the count on both from either of the two plus or two minus buttons. A more realistic use-case for this is "like" (👍 ) count, which can be sprinkled across a site which has social features.

[lucacasonato]

This is a use-case I have had myself that I have not yet found a good solution for. I have some initial thoughts on how this could be resolved, but I am open to ideas!

[nemtsov]

Hey @mandolyte thanks for the suggestion. When I tried it a few weeks ago, I couldn't get useContext to work across islands. Do you have an example of useContext working in fresh by chance?

[mandolyte]

@nemtsov Not quite... Thought I'd try and I got as far reading the state but not being able to update the state. Ran out of time... won't be back for over a week. I think another island using the same setup as shown in Counter.tsx would also be able to see the state.

But if it can't be updated by the island, then not sure how useful it is.

[mandolyte]

Code is here: https://github.com/mandolyte/experiemnt-fresh/tree/main/use-context

[mandolyte]

With a bit of debugging, I see that the context is available at build time (I think that means "on the server"), but not at run time.

A couple of console log messages show in the terminal window just fine; but not in the browser.

Thus I think, architecturally, useContext isn't being treated as useState is being treated. Someone smarter than I will have to figure this out.

[sebilasse]

@mandolyte To make it available by build time, you need to wrap it in useEffect(() => {})

import { useEffect, useRef } from "preact/hooks";

[JLarky]

have anyone tried something like that? :)

https://twitter.com/RyanCarniato/status/1542688476654493696

[mandolyte]

I have never worked with Svelte, but looked up the stores feature:
https://svelte.dev/tutorial/writable-stores

Sort of a safe global memory feature with a way to subscribe to changes. Sounds easier than useState/useEffect.

Will be interesting to see what @lucacasonato comes up with!

[amoreaulemay]

I created something similar for my own projects, you can check it out here: https://github.com/amoreaulemay/fresh-store

[czottmann]

Personally, I went with a super-minimal state management lib (in my case: https://github.com/hmans/statery). It's as simple as using useState(), it's clean and well-documented and I don't have to mess w/ the window object which is a rabbit hole on its own. ;)

Can really recommend Statery. I've tried Zustand and Valtio but in the end Statery won for its simplicity.

[xstevenyung]

Could you share your implementation as I don't see how to implement without the window trick?

[czottmann]

@xstevenyung Sure thing, here you go: https://gist.github.com/czottmann/971402a89775b261176c2fd217e82110 I've omitted TS definitions etc., it's late over here. ;)

The "magic" part is the store generation in ./stores/whatever_store.ts — the store is created only once the first time the module is loaded/ initialized, afterwards the initialized store is exported. Thus, all components using that particular store module therefore access the same data, not different instances.

The beauty here is that if you want, you can have several separate stores doing different things. In my current app one store is transiently updating the visitor's local storage w/ the store state; when the visitor returns at a later date, the store checks local storage, and if data is found uses it to hydrate the store.

You could do the same thing w/ Zustand or Valtio, of course. I just prefer Statery's super-reduced API.

[xstevenyung]

Seems to work great yet so simple, thanks for sharing 🙌

I think giving an example of this in the doc or/and in new initialized fresh project could help a lot. @lucacasonato what do you think ?

[czottmann]

It's not that Deno-specific, Steven. But I agree it could help.

While we're at it, should the Fresh team ever consider packaging a state management solution into the starter template, I vote for Statery. It's to Zustand et all what Preact is to React, after all. /㏄ @lucacasonato

[OldManFroggy]

seconded, Statery is pretty clean

[OldManFroggy]

stately is indeed nice, and is new to me -> will give it a go as Evt and local/session storage work but only for islands to get values not necessarily update other islands if values change. I have been using EVT (works well for reading, storing state, but no way to reactively get other islands to update short of a redirect), To make islands fully reactive, so that any island can affect data in another island or islands (and thus enable an island to re-actively update state) I had resorted to setting up an event listener/dispatcher model. I will play and test stately later, looks nice and clean and very Svelte Store like.

…

On Sun, Jul 31, 2022 at 11:14 AM Carlo Zottmann ***@***.***> wrote: It's not *that* Deno-specific, Steven. But I agree it could help. While we're at it, should the Fresh team ever consider packaging a state management solution into the starter template, I vote for Statery <https://github.com/hmans/statery>. It's to Zustand et all what Preact is to React, after all. /㏄ @lucacasonato <https://github.com/lucacasonato> — Reply to this email directly, view it on GitHub <#230 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATXWUNX4LJN6DVJTP63QM3DVWZGXDANCNFSM5YU77D7A> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[czottmann]

Yeah, that's one of the issues I see w/ the window approach — the utter lack of reactivity. It sounds like you then implemented a pubsub mechanism to work around that lack ("setting up an event listener/dispatcher model"). That's basically re-inventing stores. ;)

I went down the same route in the past but binding components to the "outside" (i.e. the window object) made the code harder to test; things got unwieldy fast.

[zicklag]

In Astro, which uses a similar island approach to Deno, they recommend Nanostores.

I haven't tested in fresh myself, but I haven't seen anything that makes it look like it wouldn't work yet.

[bjesuiter]

I'm building an event-bus library for exactly this use-case:
https://www.npmjs.com/package/@codemonument/event-bus-core

It's currently badly documented, but one could already poke around in the code :)
https://github.com/codemonument/event-bus-nx/tree/main/libs/event-bus-core

One particular thing I want to add is:
A Webcomponent, which itself IS an Instance of EventBus or at least a Proxy to an EventBus instance.
This Webcomponent could then be a Fresh Island in it's own right.
This would allow each Island Component to simply do a document.querySelector(prefix-event-bus) to get ahold of this event bus to share information in a pub/sub pattern, but with fully typesave events! :)

I'm curious what you all think about this idea?

[tzakharko]

Preach just announced a general-purpose reactive library that neatly integrates with the rest of APIs. Seems like a very nice fit for Fresh

https://github.com/preactjs/signals

[OldManFroggy]

yeah, but to my defense I was in a rush :)

…

On Sun, Jul 31, 2022 at 3:48 PM Carlo Zottmann ***@***.***> wrote: Yeah, that's one of the issues I see w/ the window approach — the utter lack of reactivity. It sounds like you then implemented a pubsub mechanism to work around that lack ("setting up an event listener/dispatcher model"). That's basically re-inventing stores. ;) I went down the same route in the past but binding components to the "outside" (i.e. the window object) made the code harder to test; things got unwieldy fast. — Reply to this email directly, view it on GitHub <#230 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATXWUNT4PJBERV33IFUX5BDVW2G2DANCNFSM5YU77D7A> . You are receiving this because you commented.Message ID: ***@***.***>

[czottmann]

Wasn't meant as a takedown, no worries. And that's how we learn, isn't it — throwing stuff at a wall, then see what sticks. ;)

[harrysolovay]

If there is no means of persisting application state without island-izing an entire Fresh app, does this not invalidate the architectural premise?

Sidenote: significantly hinders use cases in which wallet extensions are used for authentication / secure message signing. Aka., Fresh doesn't like Web3 :/ as a major Deno fanatic and Fresh enthusiast, I'd very much like to see these pain points resolved. Is there no way to implicitly preserve state from contexts/signals?

[JacobWeisenburger]

I'm not sure if this will work for everything, but at first glance, this seems to work
How to use some of Zustand in Deno Fresh

[marvinhagemeister]

Sharing state between islands is best done via signals. We have now a page in our docs that describes how to do that: https://fresh.deno.dev/docs/examples/sharing-state-between-islands