Advantages with complex web app

[ntarocco]

Hello,
I was wondering what are the advantages when developing complex web apps that might have multiple interactive "islands": if I understood correctly, in such cases, each island is partially hydrated, and the JS in injected in each of them.

For example, given a search page built with React and Redux, it could have:

• a search-bar in the header with autocompletion dropdowns
• a left sight bar with filters (checkboxes)
• a result container in the middle with sorting and pagination components
  They all share a common state. Each of them allows the user to trigger a new search with the selected options.

Will each island (header, sidebar, result container) inject the full React + Redux JS multiple times?
The only real advantage that I can think of is the developer experience: given that there is no building process involved (with Webpack for example), things are much easier and faster.

Or is the fresh framework, and the client hydration technique, more adapted for websites that are mainly static with not much interactivity?

[xstevenyung]

Coming from Remix or any backend framework (without SPA like rails), personally I think it's kind of a more native approach.

The state would be the URL. For example. If you change the page to go to 2, just add ?page=2 in the URL and hard redirect (there are ways to make it more "app-like"), for the search, a ?q=tool&page=2 and so forth.

It's a more native approach (closer to the browser) but add a lot of benefits with less effort, like the possibility to share a link and go back to the same state which would require Redux + React manual work to implement (or using a plugin).

In its simplest form, no JS would even be required, but you could always add / sprinkle JS as you go. For example, add autocompletion on search.

If you want a more SPA like approach, my guess would be that it could be possible to wrap a whole page with Redux, so any islands in the page could share that state (not possible at the moment as Fresh doesn't support nested islands and PR is being worked on #517) but should be achievable in the future

I like to think about modern backend framework like Fresh and Remix (to an extend) like what Ruby on Rails is trying to achieve with Hotwire but out of the box and embracing JS instead of replacing it.

This is obviously just my take.

Note: Github search is actually built on those same principal

[OldManFroggy]

or you could just use local browser state, as a form of global state for islands - of course this does not work for any static content generated dynamicly Server Side. (only for non-sensitive data of-course)

[WNemencha]

Hey guys, i've been following fresh and i have to admit i like the project, in fact i have been developing a similar one (but with node/fastify as the core). It turns out i hit a similar/same? problem.

Basically each island being not able to communicate with other islands in the same view.

I've tried to solve that the simple way by using a Context, wrapping the view with the Context's Provider, and then tried to get some data to flow through the islands.

Which never worked.

useContext alwys returned the context's initial state even tho' it was modified in multiple islands..

The main issue here is my implementation where each island is mounted individually as a call to React.render(<Island />, islandRoot); (simplified), which means different React's internal state, as i understand.

I've tried to solve it by using a global variable wrapped in an ES6 Proxy + state-memoize that, it kind of worked (poc level)

My 2 cents/story, hope that can help ;)

[OldManFroggy]

Here is a solution on how I do it with sessionState (you can also use localStorage, if you want state to persist forever for the site in a users localstorage)

to see what was done read below

from a base Deno Fresh install

deno run -A -r https://fresh.deno.dev <project name>

change /routes/index.tsx to

/** @jsx h */
import { h } from "preact";
import Y from "../islands/Y.tsx";
import X from "../islands/X.tsx";

export default function Home() {

  // lazy set of state
  sessionStorage.setItem('X', 'X Value in sessionState');
  sessionStorage.setItem('Y', 'Y  Value in sessionState');

  return (
    <div>
      {/* islands render empty divs, purpose of demo is to show islands sharing state, which can be seen server side. */}
      <X />
      <Y />
    </div>
  );
}

this index has:

• 2 islands (needed for js access to browser API's)
• 2 values set in sessionStorage -> yes its a contrived example.

Next add 2 islands (I deleted counter.tsx example)

/islands/X.tsx

/** @jsx h */
import { h } from "preact";

export default function X() {
  const X = sessionStorage.getItem('X');
  console.log('X:', X);
  return (
    <div>
    </div>
  );
}

&&

/islands/Y.tsx

/** @jsx h */
import { h } from "preact";

export default function Y() {
  const Y = sessionStorage.getItem('Y');
  console.log('Y:', Y);
  return (
    <div>
    </div>
  );
}

now when you start the Fresh site, you will see server logs showing that state was preserved from the browser and is easily accesible via sessionStorage.getItem as shown below:

$ deno task start

Warning deno task is unstable and may drastically change in the future
Task start deno run -A --watch=static/,routes/ dev.ts
Watcher Process started.
The manifest has been generated for 3 routes and 2 islands.
Server listening on http://localhost:8000
X: X Value in sessionState
Y: Y  Value in sessionState

Hope that helps?

---

ps. sorry for the rushed version did this quick, not much editing :)

[xstevenyung]

If I'm not mistaken, this approach will not trigger update for each island on change ?

e.g.

/** @jsx h */
import { h } from "preact";

export default function Y() {
  const Y = sessionStorage.getItem('Y');
  console.log('Y:', Y);
  return (
    <div>
		<button
			type="button"
			onClick={() => sessionStorage.setItem('X', 'new value')} // This will not update the island X ?
		>
			update x
		</button>
    </div>
  );

[TranquilMarmot]

This would be a good use case for Preact's Signals

https://preactjs.com/guide/v10/signals/

I haven't tried it yet, but two islands could probably communicate with signals. It would be easy to read from session/local storage and "hydrate" the signal on redirects/refreshes to persist state across pages.

[OldManFroggy]

yeah, I rushed that reply a little reply... there are a few other things you need to do to trigger updates, otherwise each islands rendering can cause some unexpected side effects. for a state change, you need to useState (initial value from state), useEffect to update the state based on changes) in some cases, you may also need to isolate the usestate/effect and state access inside a if (IS_BROWSER) block, Personally, it would be great to just have a seperate global state that is shared client/server side. very eager to find other solutions to this issue also you can always try to use another state management that is pure clientside inside IS_BROWSER (not tested yet... maybe at the weekend.) sorry for above doing from phone between meetings .:)

[WNemencha]

Just stumbled upon this while trying to solve my implementation issue, could that work so the multiple islands are "synced" thanks to the flush somehow? Gonna try some PoC and get back when (and if) i get results.

c.f. https://reactjs.org/docs/react-dom.html#flushsync

[OldManFroggy]

awesome, I was just tryting to get jotai to work but deno land build is a tad broken... I will take a look at that link also, ;)

…

On Jul 22 2022, at 9:54 pm, William Nemencha ***@***.***> wrote: Just stumbled upon this while trying to solve my implementation issue, could that work so the multiple islands are "synced" thanks to the flush somehow? Gonna try some PoC and get back when (and if) i get results. c.f. https://reactjs.org/docs/react-dom.html#flushsync — Reply to this email directly, view it on GitHub (#520 (reply in thread)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/ATXWUNUDDO6QI332M6IXYDLVVMC6XANCNFSM535JGWCQ). You are receiving this because you commented.

[WNemencha]

didn't know about Jotai, thanks for sharing that, will definitely take a look at it i already like what i see on the landing page ;)

[OldManFroggy]

Evt also looks nice

…

On Fri, 22 Jul 2022 at 22:45, William Nemencha ***@***.***> wrote: didn't know about Jotai, thanks for sharing that, will definitely take a look at it i already like what i see on the landing page ;) — Reply to this email directly, view it on GitHub <#520 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATXWUNTGBYHXB3GFOOMVJKTVVMI6DANCNFSM535JGWCQ> . You are receiving this because you commented.Message ID: ***@***.***>

[OldManFroggy]

yes, I now use preact/signals for most island and global state now. it's very clean and easy to use

…

On Mon, Oct 17, 2022 at 12:46 AM Nate Moore ***@***.***> wrote: This would be a good use case for Preact's Signals https://preactjs.com/guide/v10/signals/ I haven't tried it yet, but two islands could probably communicate with signals. It would be easy to read from session/local storage and "hydrate" the signal on redirects/refreshes to persist state across pages. — Reply to this email directly, view it on GitHub <#520 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATXWUNXDRWNEX3DP76QIDS3WDTR3JANCNFSM535JGWCQ> . You are receiving this because you commented.Message ID: ***@***.***>