6 ms·

While this page went to the top, I see a lot of comments that show people haven’t seen the other pages. I know it’s a lot to ask. But this really is a differen

While this page went to the top, I see a lot of comments that show people haven’t seen the other pages. I know it’s a lot to ask. But this really is a different programming model. It takes some time to see what it allows. I spent the last 48 hours documenting it. Here are the most important two pages: 1. https://reactjs.org/docs/concurrent-mode-suspense.html https://reactjs.org/docs/concurrent-mode-suspense.html 2. https://reactjs.org/docs/concurrent-mode-patterns.html https://reactjs.org/docs/concurrent-mode-patterns.html (especially this one!) It would mean a lot to me if you could go through both of them (including the examples) before forming a final opinion. Thank you.

alfonsodev 7y ago
Thanks a lot for taking the time to write this up, it really makes a difference.
daxaxelrod 7y ago
I'll be reading these on the subway home. Thanks for all that you've done!!
johnfn 7y ago
Thanks, Dan. You’re a hero!
sktrdie 7y ago
Hi Dan! Thanks for the great work. I wanted to discuss a few use-cases where React's new runtime model makes things less predictable: * 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?
- danabramov 7y ago
  >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. 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.
andrewstuart 7y ago
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.
- eropple 7y ago
  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.
- jpochtar 7y ago
  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 https://github.com/turbolinks/turbolinks
  - deleted 7y ago
    [deleted]
wjmao88 7y ago
Hi Dan, this is great and I really like this. But, I think what made me appreciate this is mostly your algebraic effects blog post. My issue with the examples in the reactjs doc pages is that it compares a naive and (intentionally)buggy implementation to a working implementation, so to evaluate the benefits I have to mentally fix the buggy version with existing react and compare that to the working version. It would be easier to see the difference if it could have a working implementation with current react to compare to the implementation with concurrent react. Also, I'd love to read something about why throwing promises was chosen over other possibilities.
- danabramov 7y ago
  There is more than one way to fix the buggy versions, so if we compared with a particular non-buggy version, people would complain we didn’t compare with their preferred fix. But that’s fair feedback. 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.
nightnight 7y ago
@Dan, fyi, useTransition is already used as a hook name by the quite popular react-spring animation lib. I mean, I can migrate old code bases to import { useTransition as useSpringTransition } or I just import yours as { useTransition as useReactTransition }. Not a big thing but also not really elegant. How would you deal with this?
- danabramov 7y ago
  Yeah that’s kind of unfortunate. Unintentional. I think one of us will have to rename.
  - wayneftw 7y ago
    You only have to rename if people import each hook separately. 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...
tarjei 7y ago
Hi, the docs are great - and cover a lot of ground. 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.
- danabramov 7y ago
  >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. 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.
nightnight 7y ago
From your second link: > 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
- danabramov 7y ago
  As the page mentions, we actually do move to the Skeleton state (which you’re describing) as soon as it’s possible. 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.
  - nightnight 7y ago
    > Skeleton state 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.
    - danabramov 7y ago
      >There is a name for this? Didn't know. Yes, and it's described here: https://reactjs.org/docs/concurrent-mode-patterns.html#the-three-steps https://reactjs.org/docs/concurrent-mode-patterns.html#the-t...
coldfire 7y ago
great writeup! Very easy and to the point. But if I have to suggest something (and I'm just nitpicking here), an example/section summarising everything at the end would've been the "icing on the cake". May be because I read the entire three pages in one go, I got a bit lost in the "Concurrent UI Patterns" examples, primarily when to use `useTransitions`, `useDeferredValue`, `Suspense` and various anti-patterns/edge cases that the examples mentioned :)

alfonsodev 7y ago

Thanks a lot for taking the time to write this up, it really makes a difference.

daxaxelrod 7y ago

I'll be reading these on the subway home. Thanks for all that you've done!!

johnfn 7y ago

Thanks, Dan. You’re a hero!

sktrdie 7y ago

Hi Dan! Thanks for the great work. I wanted to discuss a few use-cases where React's new runtime model makes things less predictable: * 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?

danabramov 7y ago
>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. 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.

andrewstuart 7y ago

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.

eropple 7y ago
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.
jpochtar 7y ago
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 https://github.com/turbolinks/turbolinks
- deleted 7y ago
  [deleted]

wjmao88 7y ago

Hi Dan, this is great and I really like this. But, I think what made me appreciate this is mostly your algebraic effects blog post. My issue with the examples in the reactjs doc pages is that it compares a naive and (intentionally)buggy implementation to a working implementation, so to evaluate the benefits I have to mentally fix the buggy version with existing react and compare that to the working version. It would be easier to see the difference if it could have a working implementation with current react to compare to the implementation with concurrent react. Also, I'd love to read something about why throwing promises was chosen over other possibilities.

danabramov 7y ago
There is more than one way to fix the buggy versions, so if we compared with a particular non-buggy version, people would complain we didn’t compare with their preferred fix. But that’s fair feedback. 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.

nightnight 7y ago

@Dan, fyi, useTransition is already used as a hook name by the quite popular react-spring animation lib. I mean, I can migrate old code bases to import { useTransition as useSpringTransition } or I just import yours as { useTransition as useReactTransition }. Not a big thing but also not really elegant. How would you deal with this?

danabramov 7y ago
Yeah that’s kind of unfortunate. Unintentional. I think one of us will have to rename.
- wayneftw 7y ago
  You only have to rename if people import each hook separately. 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...

tarjei 7y ago

Hi, the docs are great - and cover a lot of ground. 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.

danabramov 7y ago
>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. 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.

nightnight 7y ago

From your second link: > 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

danabramov 7y ago
As the page mentions, we actually do move to the Skeleton state (which you’re describing) as soon as it’s possible. 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.
- nightnight 7y ago
  > Skeleton state 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.
  - danabramov 7y ago
    >There is a name for this? Didn't know. Yes, and it's described here: https://reactjs.org/docs/concurrent-mode-patterns.html#the-three-steps https://reactjs.org/docs/concurrent-mode-patterns.html#the-t...

coldfire 7y ago

great writeup! Very easy and to the point. But if I have to suggest something (and I'm just nitpicking here), an example/section summarising everything at the end would've been the "icing on the cake". May be because I read the entire three pages in one go, I got a bit lost in the "Concurrent UI Patterns" examples, primarily when to use `useTransitions`, `useDeferredValue`, `Suspense` and various anti-patterns/edge cases that the examples mentioned :)