It’s a bit tricky because as the docs explain, the only Suspense integration we currently use in production is Relay. I definitely agree we need a complete Relay example that people can run (maybe Relay docs have one already?). But a lot of people don’t know Relay so it would be hard to teach both new UI patterns like useTransition and Relay at the same time. This is why we didn’t do it in the main docs.

How a form would work really depends on how your data solution manages a cache. Relay has one answer for that, some other solution may have completely different answers. So I wanted to keep the first examples simpler and less opinionated.

As more libraries start to integrate Suspense I think you’ll see more such complete examples. But this release wasn’t for the end users as much — it was more for people who would create those libraries.

Hope that makes sense.

Maybe I just missed this, but I couldn't find any kind of guidance for library maintainers on implementing Suspense. Reading the demo code + React-Cache it seems that it's basically about providing an interface that throws unresolved promises, but is there any more detailed documentation?

We'll likely add more documentation about this -- however, indeed, the contract fits in those 10 lines. There's not much more that's needed on the integration side.

The real questions (where and for how long do you cache, what triggers are fetch, how to avoid waterfalls) are something that the library itself is better positioned to answer and figure out. We don't have a particular suggestion there (although the docs mention our recommendation).

> depends on how your data solution manages a cache

> But this release wasn’t for the end users as much — it was more for people who would create those libraries.

Where is the documentation to create these libraries (cache integration, etc)?

Every example on those pages has a reference toy implementation in `fakeApi.js`. You can use it as a base -- that's the whole contract that React cares about. We'll describe it in more detail later.

Thanks a lot Dan

This is one of the real bummers about the growth of the "ToDoList" app as the "Hello World" of these frameworks. It's really important to demonstrate backend communication.

Rails is probably a better fit for your needs. If you're primarily concerned with sending forms to and showing data from a server, React isn't going to give you much.

React is great for Figma, Dropbox Paper, Coda, and Pagedraw: apps that are basically entirely local, and may or may not happen to be syncing with a server in the background.

CRUD is a special case of app, and the modern HTML/CSS/JS browser is pretty well tailored to handle all the needs for the client side of one. Maybe sprinkle in some Turbolinks [1] if you want some fancier page transitions.

It'll take time before someone makes a good CRUD framework on top of React. Until then, Rails is a great CRUD framework, and isn't missing much I'd expect to see React solve.

[1] https://github.com/turbolinks/turbolinks

If you're not living in a first world country (or living in Germany lol), you usually don't have a stable internet connection. I've developed a lot of CRUD apps that are core to many businesses on field and without ServiceWorkers (or the manifest based appcache before) and client side databases that are better suited to use from SPAs, I'd rarely have success in any of those projects.

You don't really need a framework for this. Forms are incredibly easy to handle from React. A framework for declaratively caching relational data with server side components (like poachdb but for SQL server) would have been amazing though.

I don't know Turbolinks enough but it doesn't help with the connection problems I assume?

No, it does not. Turbolinks keeps a local cache of previously visited pages so transitions to those seem instantaneous, but this is session-only and can't be populated in advance.