0.0.3: A fun toy

[chrisdmacrae]

0.0.3

This version is a fun toy. But it can't really be used for building apps. Far from it.

Right now it allows creating a full temporary session, client-side or server-side, for an Astro site to allow for keeping track of state in an Astro site.

This allows you to have a server-rendered app, or a client-rendered app, that has persistence and whose islands don't fail to hydrate if server side rendered, which is a great first step.

What problems does it have?

1. A statically rendered SPA can't have server-side rendered components, because of the hydration logic.

• This strikes me as sort of useless.

2. You have to buy, all-in, on the store abstraction to get value. It's heavy handed, but maybe necessary.

• This is because the behaviour of the abstraction means components unmount and re-mount between page routes; any in-framework or vanilla "on-page" state is clobbered on every page change.
• Frameworks like Next, Remix, etc allow us to have a core application shell that doesn't re-render between page views.
  • This could be achieved by having core components that are rendered outside of the SPA. Will need to experiment.

3. The session is ephemeral; this is only valuable as a play-toy for unimportant state.

What's valuable right now?

Routing

The routing behaviour is valuable for creating a dynamic experience. It allows you to create the kind of experience people come to expect from a dynamic site, and it's lightweight (under 15kb) and file-system routing aware.

This is probably the most valuable part of this experiment right now.

Request chain persistence

Request chain persistence means as long as the user continues an unbroken chain of requests, their UI state is preserved.

How do other frameworks do this?

They don't. They persist state in the browser.

If you need to do a round trip to the server, you're recreating the universe from scratch.

What's maybe not valuable?

The store abstraction

It's cool. It's a fun toy. It probably doesn't lead to a ton of extra value as-is. An ephemeral state is not super useful, so the footprint it adds to code is not that valuable.

What does it need to be valuable?

It needs a real application lifecycle. Let's think about this for a minute...

Getting data to the page

Right now this abstraction synchronously requests the data a page needs, be it from a store, content collections, or a third-party API.

Anything passed to a store, a script tag, or an island is serialized to the DOM for hydration.

Submitting data

A form submission needs persistence. This needs to happen outside of Astro for obvious reasons (we don't want a temporary server holding that state).

However the DX of creating interactive forms could be greatly improved. Imagine being able to use a thin API to couple pages to their data submission, and having that coupling be at the page level. No making a separate API that handles your submissions -- instead you build pages that serve the UI, both literally and figuratively.

When a page is pre-rendered, a separate API route is required. Patterns can make this feel better.

Error handling

If you want to GET data or submit data, errors suck. You have to handle them totally manually with procedural logic.

Let's automate this in some fashion.

Persisting state outside of request chains

Cookies are the obvious first step. They need to be secure, protected against XSRF, XSS, etc.

The next obvious step is going to the outside world. What makes this hard in Astro is that every page is an island -- its own server less function or endpoint and sharing context between them is hard.

Stores attempt to solve this, but right now they're extremely procedural. You need to explicitly state which stores you want to use and hydrate them accordingly.

Right now stores are totally isomorphic, meaning making private stores is hard.

Streaming as a tool

Astro supports synchronous streaming. Async components, Astro or otherwise, stream in order.

This means a clever person can make slow things feel fast by sequencing them correctly.

We need to take advantage of this.