Comment by andrewstuart | Hacker News Reader

Comment by andrewstuart | Hacker News Reader

Parent Full thread

Thanks to Dan and the React team - great work as always.

The most useful thing to provide with this would be a small self contained example of the absolute core of all web programming - a form that gets data, submits it to the back end, and then displays a list of records. Nothing more. Super simple. All web development knowledge derives from this start point - for me anyway.

This is what underpins all web development and when I come into a new approach like this I always aim to implement that basic display/submit/list form workflow.

It would be SO helpful if that existed as a small standlone application.

The profile stuff is in the right direction but not it.

When there is not a basic example of that exact workflow then the cognitive load instantly skyrockets because I now need to work out how to do that and even then I don't know if I got it right because it's my guess using a technology I do not understand. So much better for the technology designers to show how to do the core of all development "the new way". Ideally with a standard form and not graphql.

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.

Reply on news.ycombinator.com