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.

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.

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).

> 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)?

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

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?

> if we switch from one page to another, and none of the code or data for the next screen has loaded yet, it might be frustrating to immediately see a blank page with a loading indicator.

IDK what's the best or most accepted UX. But my gut feeling says an instant transition to the new page with light grey pulsating placeholders rectangles for the still to load contents gives the highest user satisfaction. This feels super responsive and is learned by the users for years (and it's perfectly do-able just with Suspense).

So, I wonder if the solution of clicking, seeing no change but a small loading sign or spinner next to button till the page really is transitioning is actually that more responsive/satisfying? I really don't think so, it rather makes the app feel more sluggish, reminiscent of the old days with server-rendered pages and not feeling like a actual SPA.

This is of course debatable but are there any other significant/killer use cases React Concurrent makes possible? I don't want to sound snarky but I've the feeling Concurrent is a solution with a slick name searching for a problem. I hope I am wrong.

Edit: To the pro downvoter, just try to articulate your thoughts and contribute to a discussion than pure downvoting

We’re only delaying the transition for as long as we have nothing good to show at all. When we have a decent loading state, we immediately transition to it.

I do recommend you to play with it more in a tiny project.

There is a name for this? Didn't know.

> I do recommend you to play with it more in a tiny project.

Ok, will do.

Yes, and it's described here: https://reactjs.org/docs/concurrent-mode-patterns.html#the-t...

* Suppose you want a :hover CSS selector to be applied at the same instant as a state change triggered by that hover. It's no longer reliable. Hence you're stuck with having to change the DOM in response to the state change to match a different selector.

* The browser may often set component state via its own behavior. (Small contrived ex: setting the scrollTop position of an inner element based on tabbing to a link.) Pretending that virtual DOM represents DOM, especially at X time, can get you in a lot of trouble.

How would you deal with these contrived (yet realistic) examples?

Not sure I understand the problem. Can you make a CodeSandbox demo? That said you can always wrap an update in `ReactDOM.flushSync(() => { ... })` to force it to run synchronously. But I'm not sure I understand the scenario or which problem you're referring to without a concrete example I could run.

>The browser may often set component state via its own behavior. (Small contrived ex: setting the scrollTop position of an inner element based on tabbing to a link.) Pretending that virtual DOM represents DOM, especially at X time, can get you in a lot of trouble.

I don't understand what this means. Again, a concrete demo would help ground the conversation. I think you might have some flawed assumptions about what React does, but I can't tell for sure because I don't understand what you're saying.

Thank you!

It's worth saying we've been using Concurrent Mode in production for about a year now. There are some snags we still need to solve, but they don't sound a lot like what you're describing.

The React team is doing amazing work!

Two questions / inputs:

1. Are the "Progressive Hydration" and "Selective Hydration" related to SSR? I could not find any info on what functionality is hiding behind the terms.

I've been wondering about how selective hydration could work with SSR.

2. In general I often find it hard to navigate the API part of the React docs - for example to find the definition of a lifecycle method (for example componentDidUpdate). There is no fast way to get to a single method.

I think this might be because the pure API docs feel a bit mixed into the rest of the documentation and therefore read more as complete articles than single packets of information.

Yea. We'll need to expand the docs on this. Progressive Hydration means React won't block the thread while hydrating HTML. Selective Hydration means you can tell React to prioritize hydrating a particular subtree (e.g. because the user interacted with it).

>2. In general I often find it hard to navigate the API part of the React docs - for example to find the definition of a lifecycle method (for example componentDidUpdate). There is no fast way to get to a single method.

I'm not sure what this means. If I type "componentDidUpdate" in top right search bar, it jumps directly to it.

Also, I'd love to read something about why throwing promises was chosen over other possibilities.

Regardless of the comparison, the features described on the “Concurrent UI Patterns” as the real deal. The “old” ways of doing things don’t allow to do any of them as expressively.

Not a big thing but also not really elegant. How would you deal with this?

I prefer to use React.useWhatever(); so I don’t have to keep going to the top of the file and importing new things.

Is my preference wrong? Much of the code that I see online does not use my preference...