20 ms·

React Concurrent Mode

• duxup 7y ago
  It's certainly a problem I sort of dance around in React planning how and when something might render based on what is going on, the amount of rendering and such, and the dance is somewhat never ending.
  • mosdl 7y ago
    One of the main weaknesses of vdom is that React now has to solve these issues that browsers already do natively.
    • ng12 7y ago
      Can you elaborate? At a minimum vdom is just doing work you would have had to do manually with DOM apis.
      • mosdl 7y ago
        With regular dom/javscript, you can be typing into an input field and updating unrelated DOM and the typing should not be impacted much (unless you are changing a lot of DOM and spiking the cpu). But with React it has to reconciliate the input field.
        • acemarke 7y ago
          "controlled inputs" are certainly the recommended React idiomatic pattern, but you can use standard uncontrolled inputs if you want.
    • duxup 7y ago
      I kinda wonder how the regular dom would solve some of this. I mean just rendering a ton of stuff my browser will hang up on straight html page too. Granted that's a very general example and Concurrent is solving some things that in some cases aren't quite 1:1.
• zyang 7y ago
  "For IO-bound updates (such as fetching code or data from the network), concurrency means that React can start rendering in memory even before all the data arrives, and skip showing jarring empty loading states." What is there to render but loading states when there's no data?
  • jacobr 7y ago
    Buttons, headings, labels... Will all be ready when your data arrives.
    • JMTQp8lwXL 7y ago
      You can already do that without concurrent mode, though. Let's say you have a navbar (your website's header), a list of things asynchronously retrieved from an API, and a footer. const myApp = () => ( <Header /> <Body /> <Footer /> ); Body can make the network request, and store the result in state. Since the network request took 200ms, Header and Footer have already rendered.
  • xtagon 7y ago
    Stale cached data.
  • PKop 7y ago
    >when there's no data Everything else, or nothing prior to some threshold, or what you specify and where within the Suspense abstractions. Since you don't know exactly when all of the data is ready in different parts across time, manually coordinating all of it without a cohesive declarative paradigm results in more code and more errors, and more bad UX of flashing spinners and flickering loading states. The point of concurrent rendering and Suspense are to abstract at a higher lever, or more general terms what to do and what to render when there's no data.
  • the8472 7y ago
    Perhaps he meant "before all of the data has arrived", i.e. some of it is already available.
  • 7y ago
• boucher 7y ago
  Pretty interesting. Hope someone also writes a summary of how it works. Are they computing the tree in a worker, or have they just modified the rendering api itself to somehow be interrupt-able?
  • boucher 7y ago
    Seems someone has written some of it up here: https://github.com/acdlite/react-fiber-architecture https://github.com/acdlite/react-fiber-architecture
    • petetnt 7y ago
      acdlite has written most of the implementation work that lead to this feature
    • fourthark 7y ago
      (2016) - this stuff has been a long time coming
  • acemarke 7y ago
    Rendering becomes interruptible. In Concurrent Mode, React will split the work of a single render pass across multiple chunks as time exists within a single frame, yielding back to the browser as needed to let it process events. Once the whole render pass is complete, React will finally "commit" the changes to the DOM. If a user input or other render - triggering event occurs partway through a render pass, React can set aside its partially completed calculations, start a new render pass, complete that and commit it, then effectively "rebase" the original changes on top of the just-applied change. Shawn Wang has been collecting links to all the info on Concurrent React that's been released over the last couple years : https://github.com/sw-yx/concurrent-react-notes https://github.com/sw-yx/concurrent-react-notes
• manigandham 7y ago
  These frameworks should be architected to support async/await scenarios natively instead of all these convoluted workarounds. Promises/async have ben around long enough. EDIT: JS is already dynamic. If a function returns a promise then it should be awaited and render blank or nothing in the vdom. This is obvious, except in JS where architecture prefers synchronous-only design with async being an afterthought.
  • arcticfox 7y ago
    React's prioritization of features has led to it being one of the most successful frameworks of all time, I'm not sure how useful it is to suggest they should have started with this from the beginning. It's been overwhelmingly successful without this feature.
    • manigandham 7y ago
      It's popular so it's fine? The massive number of async-related workarounds, libraries, tooling and code practices says otherwise. jQuery is even more popular btw. It's the general state of Javascript and frontend code which is finally starting to understand what multithreading and concurrency is.
      • ng12 7y ago
        JavaScript is not multithreaded.
        • manigandham 7y ago
          Javascript as a language isn't, but Javascript code can use multiple threads in various ways.
          • ng12 7y ago
            And you're implying asynchronous coding is new to JavaScript developers?
• EastSmith 7y ago
  The version control analogy in the description was spot on, but a good demo is worth a thousand words, so I will be waiting for a good demo to make conclusions.
  • throwaway_bad 7y ago
    The clearest demo that communicates what this solves was given when it was announced last year. That clock animation is pure genius: https://youtu.be/nLF0n9SACd4?t=473 https://youtu.be/nLF0n9SACd4?t=473
  • gmaster1440 7y ago
    This CodeSandbox seems relatively instructive: https://codesandbox.io/s/frosty-hermann-bztrp https://codesandbox.io/s/frosty-hermann-bztrp
    • jbaudanza 7y ago
      This demo is helpful. One thing that stands out is that fetchProfileData is made in the global scope. I presume (I hope) that it will be possible to do this from include an useEffect hook instead.
  • the_duke 7y ago
    I think CPU branch prediction would be a better analogy. But version control is a lot more approachable.
  • danabramov 7y ago
    It might be asking a lot but to form the right impression, I would really suggest that you get through these docs: 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 I spent the last 48 hours writing them, and I think they answer your questions and contain many, many demos.
    • koolba 7y ago
• dosy 7y ago
  Yaaaaawnnnnn
• rubyn00bie 7y ago
  Is this just using generators to allow things to be interrupted and scheduled? Or is it more fancy than that?
  • aocenas 7y ago
    Last time I seen an explanation for this, they were talking about throwing and catching promises. So you could probably implement suspense with an error boundary just checking if the error you got is actually promise and if so wait for it to resolve until rerendering. But reading this I think there is a bit more to it and I would assume for some things to work you have to actually try rerendering on some scheduler not just wait for promises to resolve (like they mention in how multiple Suspense components are aligned and rendered together if they resolve in close succession)
    • bnjmn 7y ago
      Here's a comment from Sebastian M (React core team member) about why they chose not to use generator functions: https://github.com/facebook/react/issues/7942#issuecomment-254987818 https://github.com/facebook/react/issues/7942#issuecomment-2...
• aocenas 7y ago
  Anybody knows whether generator functions were considered and if they were, reasons why they were not used for this?
  • bnjmn 7y ago
    Yes! I was also curious about this, because I'm sure you could make generators/yield work for asynchronous interruptible rendering, but here's what the React team has to say: https://github.com/facebook/react/issues/7942#issuecomment-254987818 https://github.com/facebook/react/issues/7942#issuecomment-2...
• holler 7y ago
  As someone who mostly uses ember.js in the day-to-day, I'm wondering how this compares to the amazingly great ember-concurrency library that uses generators?
  • bnjmn 7y ago
    Here's their official position on generators: https://github.com/facebook/react/issues/7942#issuecomment-254987818 https://github.com/facebook/react/issues/7942#issuecomment-2...
    • holler 7y ago
      very insightful, thank you
  • danabramov 7y ago
    This is solving somewhat different problems. I strongly recommend to go through the examples here: https://reactjs.org/docs/concurrent-mode-patterns.html https://reactjs.org/docs/concurrent-mode-patterns.html. I think it’ll make more sense then.
    • holler 7y ago
      thanks!
• anderspitman 7y ago
  On a purely technical level, this is really cool. But I can't help but wonder: if this level of complexity is the answer, maybe we're asking the wrong question.
  • hombre_fatal 7y ago
    Clients are never as simple as people seem to think. Look at how complex the iOS/Android stacks are, and they aren't even crossplatform like web is.
  • deleted 7y ago
    [deleted]
  • huy-nguyen 7y ago
    Correct me if I'm wrong but I think the reason for all the ceremony you're seeing is that React is trying to implement algebraic effects in JavaScript, which doesn't support them and neither do most other languages.
  • draw_down 7y ago
    "Too complex, but I can't come up with anything better"
  • Grzegrzolka 7y ago
    I am huge React fan, but when I see how complicated are some of the modern React codebases in some "leading" companies I have a strong feeling that we will soon need to go back to drawing board and hit some kind of reset button. As I said, I love React ecosystem, but there is something fundamentally wrong with most front-end developers today. They build bigger and bigger SPAs because they are confident that React ecosystem makes it maintainable, well good luck maintaing React/Redux/Graphql/hooks/bazillion-libs after 5 years. Abstraction is good, but it has its limits.
    • nickdandakis 7y ago
      Sometimes frontend developers overengineer their solutions, yes. Sometimes you need a more complicated solution for a complicated set of requirements. Do you need GraphQL? Nope! Do you need GraphQL for an application that needs to fetch a lot of highly relational data with nested objects? No, but it sure would be more optimal to just ask for what you need in one request in the shape you expect, instead of either: a) Multiple REST API calls that you need to combine and coordinate in the frontend b) A specialized REST API call that gives you all the data you need in the shape you want, but it isn't very RESTful c) A REST API call with a bunch of `with[]` params (a la Laravel) that indicate what nested objects you'd like, but not their exact shape So, which is more maintainable then? — The other wild misconception I see time and time again is this: Of the five things you mentioned "React/Redux/Graphql/hooks/bazillion-libs", only the first one is React, and the second-to-last (Hooks) of which it is optional. The rest are dependencies you opt for, hopefully after weighing pros and cons. You don't need to use Redux, GraphQL, react-table, whatever other dependency in your React web application. Please separate out React from React-based codebases from code architecture. They're not one in the same.
• couchand 7y ago
  This is a wonderful example of a well engineered solution to the wrong problem. React is a wonderful view library, and if limited to that use it is remarkably fast and easy to use. But the usual way of building things is to treat React as a total web app framework. The terminology is very confused: they still call it "rendering", even though it now usually includes data fetching, complex manipulations, event processing, etc. You just `React.render` once when your page first loads and then child components take care of the rest. It should really be called `React.start`. > The reason for the stutter is simple: once rendering begins, it can’t be interrupted. Rendering should never need to be interrupted. If your app is architected to have any rendering operation take long enough that it's perceptible to the user, STOP DOING THAT THING DURING RENDERING. Want a performant web app? Apply separation of concerns properly, and limit your use of React to the view layer.
  • MuffinFlavored 7y ago
    Without data fetching or manipulating, you have nothing to render.
    • couchand 7y ago
      Yes, but don't do it from within your view. Fetch the data you need and provide it to the view. The standard React application renders a few levels down, investigates the document location and matches against routes, renders a few more levels, discovers there is some necessary data missing, fetches it, renders a few more levels down, realizes there's more data missing, stops and waits for it, etc. This isn't a failing of React per se, but rather of how people use it.
      • weberc2 7y ago
        As an ignorant and neutral bystander, I’m really curious why this is downvoted and would be interested in reading the rebuttal (seems like I could learn something).
        • chacham15 7y ago
• jbaudanza 7y ago
  As I understand it, the principal behind the VDOM is that renders are cheap and the cost is is negligible compared to real DOM updates. If this is the case, why do you need to keep concurrent VDOMs in memory at once? Why can't you just render the VDOM you need when you need it? I think this is where I'm getting lost on this new feature.
  • chacham15 7y ago
    The problem is that you want to be able to abandon work (e.g. due to new data coming in that invalidated the previous data). So, what you need is to go back to the last complete render and start applying your changes from there. If there were partial changes applied from before, you cant just skip the middle update.
    • jbaudanza 7y ago
      OK I've spent all morning reading about this. I think that when you say "work", you're talking about the work of doing DOM updates. Rendering a VDOM is still considered cheap.
      • joe_hoyle 7y ago
        The "work" is the arbitrary JavaScript in the `render()` function. In Concurrent mode, a `render()` function that renders 1000 children can now be interrupted "between" renders of all those children. It's akin to doing `Header( LoginLink( GetLoginName() ) )` versus ``` Header(); check_for_interrupt(); LoginLink(); check_for_interrupt(); ... ``` The interrupt between rendering components (pieces of work) can now cancel the whole render operation (because say, the parent component has now been updated / wants to be re-rendered), or can pause the render tree while something like a high-priority animation frame is rendered.
  • danabramov 7y ago
    The thing that’s slow is arbitrary JS code people write in components. VDOM is not the point there. We want to make arbitrary JS code people write non-blocking, by using components as the “units of work” where we can yield. Really though, you’re over focusing on the CPU part. The IO part is much more interesting.
• adriancooney 7y ago
  Huh. Throwing promises to manage concurrency is kind of neat and scary (because it's new and different). I remember there was huge performance hit from functions containing `throw` statements in V8, has that been addressed (in V8 or in this project)?
  • lhorie 7y ago
    Yes, in V8's Turbofan
  • danabramov 7y ago
    If you’re blocked on network, throw is not gonna put a dent in that. We only use throwing when work is blocked on IO.
• Phillips126 7y ago
  I'm a developer who primarily uses ReactJS for the front-end. I chose the library years ago because it just made sense to me. I really liked the syntax (JSX), the lifecycle methods and the quick hot reloads. The only thing at the time that I really didn't like was the build system (browserify, gulp, webpack, babel, etc) as I found it overly complicated. Now all of that is basically invisible with "create-react-app" and I can just get right to building applications in seconds - life is pretty good. With each React update however, I worry that ReactJS's scope/concerns is growing far beyond the view layer that is was initially designed to be. I worry that it will become just another bloated "framework" with unnecessary complexity and drive me into the lighter weight and more focused alternatives such as VueJS or Svelte. Perhaps the React team is getting bored? IMO I'd like to see a base ReactJS with these advanced features being add-ons in some fashion. Keep the version I like to use lean and the complexity just where I like it.
  • PKop 7y ago
    > I worry that ReactJS's scope/concerns is growing far beyond the view layer that is was initially designed to be. It is. Because through experience developers realized these concerns need to be addressed, and handled... by something. It is unavoidable to have a useful application. Having the framework integrated to help you do so is much less painful than piecing together separate tools, or having 20 different libraries construct their own way to do so (if it is solveable in a uniform way that simply needs to be advocated and agreed upon). But in any case, why can't you just not use them? What is the pain point caused by ignoring the changes... and choosing separate tools to solve these problems if that's what you prefer?
    • jabits 7y ago
      Well, with any large, complex system, you have to learn enough about everything to know what not to use. I have been developing applications of many types for decades and it seems every time I look at react (I am responsible for one production react app that I did not write) it seems there is some new major change on how to approach the entire framework...it's daunting. And with all the constant changes to the main underlying technologies (HTML, CSS and JavaScript), it's even more so...
• jonkoops 7y ago
  This is a good development. Honestly one thing I very much think is a downside about React is the fact that your template is also JavaScript. Don't get me wrong this is incredibly powerful and can be very expressive, but it comes at a cost. That cost has the same cost as other JavaScript - it's blocking, cannot be paused and has all the possibilities of de-optimizations that might occur in the JIT. The Ember team faced a similar problem in the past and I find their solution to this problem quite intriguing, even in it's obscurity. Instead of compiling their templates to JavaScript they instead compile them to opcodes in a binary format which is executed by a virtual machine. This has several advantages. Since the template file is represented as an optimized binary the size of the file itself is incredibly small, excellent since templates can be a large part of your eventual code. Not only that but since the instructions are opcodes, this mean the VM can pause at a moment when the browser is too busy with other stuff. Since a large part of your templates is probably static and not prone to any changes the template file also indicates which parts of the instructions are dynamic and which are static. This allows the VM to generate a separate set of instructions just for subsequent updates, only updating those parts which are dynamic. Now I am not saying this is a silver bullet, it is however an interesting and fresh approach. In case you're interested in this check out the Glimmer site or Tom Dale's excellent talk (can't recommend this enough) on the subject: - Tom Dale's talk: https://www.youtube.com/watch?v=nXCSloXZ-wc https://www.youtube.com/watch?v=nXCSloXZ-wc - The Glimmer JS site: https://glimmerjs.com/ https://glimmerjs.com/
  • maxkwallace 7y ago
    All good points. Haven't read the code so I don't know how deep the similarity goes but the new React Concurrent UI Patterns is at a surface level conceptually similar to Ember's interruptible route transitions, though more fine-grained. Also really like the new <Suspense> Component! I created a {{render-on-resolve promise=foo}} Component for the app I worked on in Ember back in 2016, and we got a ton of use out of it. If you set up your data layer right, and use it well, it completely removes the need to ever manually manage a loading spinner again.
  • AgentME 7y ago
    It's true that React can't pause in the middle of any individual component's render function, but when there are many components being rendered, React is able to pause and interrupt rendering between different component instances' render functions.
• goliathDown 7y ago
  I'm relatively new to ReactJS and professional web development, and I've been using (and learning) react-redux. The layer schema makes sense to me; React handles user input, redux manages state, and react-redux ties them together. If react does a better job at speedily handling user input to the point of seamless interaction, then I suppose that would be good. What are we losing from choosing to make a layer itself responsible for the speed of returning output (rendering) from input (user interactions)?
• throwaway_bad 7y ago
  Throwing promises to emulate algebraic effects seems really hacky. I wonder if React would've needed to go down this path if they were built by a different company. For example Google/Apple/Microsoft all have huge influence over browser implementations (chrome/safari/edge respectively). They might've been able to push a ECMAScript proposal for proper language support instead. It's a very clever hack regardless but it only seems necessary because Facebook doesn't have control over the whole stack. (it does seems like Facebook trying to fix this by building their own React-optimized javascript engine but only for react native on android right now: https://facebook.github.io/react-native/blog/2019/07/17/hermes https://facebook.github.io/react-native/blog/2019/07/17/herm...)
  • underwater 7y ago
    Members of the React team are active in TC39. There are some features of React that have been replaced by language features (like spreading props into another component).
  • davnicwil 7y ago
    > push a ECMAScript proposal for proper language support instead I don't think this is the way it does (or should) work, though. No company should be able to just come up with essentially an application layer pattern and immediately push that pattern down the stack, just because it's their idea and they think it's good. A pattern needs to get a lot of practical usage, be iterated on a lot, and have strong consensus behind it before it's pushed down the stack to become a more fundamental building block in ECMAScript / browser APIs. It's a form of make it work -> make it good -> make it fast. The process should take years. It's what happened with jQuery which eventually inspired the native DOM selector APIs, and I think the same is happening with React. I honestly wouldn't be surprised at all to see JSX standardised as part of ECMAscript within the next 5 years. The rest of the stuff they're doing with the fibre architecture etc may follow too, eventually, if it turns out to be a really good idea after years of people using it in practice and agreeing it really ought to be part of the stack.
    • erikpukinskis 7y ago
• foota 7y ago
  This was the biggest pain point I had when developing a vanilla react app circa two years ago. It's great to see that they've come up with a neat solution that works out of the box!
• sktrdie 7y ago
  Any framework that allows me to write simple code which then gets _automatically_ highly optimized to run efficiently and with high/low priority based on the user-interaction and effectively removes race-conditions and makes it more intuitive to deal with loading states is a good thing for me. In fact this feels so advanced stuff (React's runtime I mean) that it will probably one day land in the browser. So React's team is just one step ahead of the others, they are thinking: "what's the least amount of code we can let developers write so that we can optimize away all the rest of the stuff?". One thing I'm worried is whether with all these amazing optimizations and very different code-execution model, we have to rethink some of the valuable simple lessons of software architecture we learned over the years. For instance, we have to rethink a bit about how to organize code and how to test it. Some things that before we could confidently say "this piece of code will run at this time" will now be a bit more like "not sure when this piece of code will run". Cool stuff, but some tradeoffs to consider.
• iamleppert 7y ago
  This isn't new. You've always been able to build up a DOM element in memory before adding it to the tree. You can even use something like requestAnimationFrame to incrementally build and not block (useful for things like long lists etc).
  • danabramov 7y ago
    For sure. But I’d love to see a demo of features described here that’s as expressive. The challenge isn’t the low level mechanism. It’s how to make it composable so people can build their own abstractions. https://reactjs.org/docs/concurrent-mode-patterns.html https://reactjs.org/docs/concurrent-mode-patterns.html
• kansface 7y ago
  I'm left scratching my head a bit from this blog post. In https://reactjs.org/docs/concurrent-mode-suspense.html https://reactjs.org/docs/concurrent-mode-suspense.html, current pitfalls of fetching data are explored including waterfalls (sequential loading spinners for nested components) and data races. The way we currently solve these problems, which for some reason didn't make it into the examples, is with Redux: fetchProfileData() const ProfilePage = connect((state) => ({ user: state.user, posts: state.posts})(ProfilePage) In truth, we'd also track a loading and error state as well. This solution is not subject to data races or waterfalls. One could argue that their new implementation provides a better interface... but I'm not so sure. The final ProfileDetails won't work outside a Suspend because the Suspense API is Throwing Promises [1]. In fact, it crashes the app :-/ Note how we eliminated the if (...) “is loading” checks from our components. This doesn’t only remove boilerplate code, but it also simplifies making quick design changes. Yeah, I did note that, but is it a good thing?! Rendering in React is currently localized to the render function of the Component itself! Its rather easy to miss the function call that is throwing a promise during rendering to cause itself to not be rendered! Suspense is a hidden interface to delegate rendering to a parent - perhaps an even more error prone Context API. All in all, this feels like Hooks to me - the trivial examples in the Docs seem perfectly cromulent, but in practice, the ergonomics are so bad that any time I try to use them, I am forced to spend several hours debugging stuff because they lose predictability when composed. Perhaps this won't be so bad in practice, but I'm having a hard time imagining how to compose components that interact with Suspense. Of course, I'd love to be wrong (about the API) or proven wrong and everything turns out to be magical. Maybe TS makes it perfectly obvious in practice, but maybe it generates a ream of gibberish instead. The true sleight of hand in most of the examples is to kick off `fetch`ing before a component gets mounted that needs the data: // Kick off fetching as early as possible const promise = fetchProfileData(); function ProfilePage() {}... As far as I can reason, there is no good way to do this. The data dependency graph is naturally defined by the component graph: after all, components know what data they need to render, but that graph can't be resolved until after they are actually rendered. So, you end up defining it in two places with an implicit coupling or via HOC or get a waterfall. I'd be open to some magic here. 1. https://codesandbox.io/s/frosty-hermann-bztrp https://codesandbox.io/s/frosty-hermann-bztrp - see fakeAPI.js (couldn't figure out how to link to it.
• XCSme 7y ago
  As an experienced front-end developer I must say that I don't really understand why the complexity of building websites is growing instead of going down. We have build thousands of front-end frameworks and all of them try to solve the same issues that should have been solved by the browsers themselves a long time ago. We implement complex "routers" and "server-side-rendering" to show specific content when the URL in the address matches a specific value, while the entire web architecture was made exactly for this purpose, to show some content when you go to an URL. Tens of years of "evolution" and we just keep making everything slower and more complex for no reason, apart from being bored or wanting to be trendy. I know all those frameworks exist to solve a specific problem, but while doing so we are creating hundreds of problems that never existed before.
  • kylemh 7y ago
    You likely don't have the problems that Facebook is trying to resolve with React. Namely, developing something once and having it work ideally everywhere on the planet (slow network vs. fast network). They're worried about shaving kilobytes here and there - concurrent mode helps to dynamically render/load items in an order that makes sense for people on slow networks where it wouldn't even matter for people on fast networks.
    • onion2k 7y ago
      You likely don't have the problems that Facebook is trying to resolve with React. Namely, developing something once and having it work ideally everywhere on the planet (slow network vs. fast network). Providing users with the best experience possible in their browser regardless of the limitations of their computer and network is a problem every front end developer should be trying to solve. Very few of us work at the scale of Facebook, but that particular problem isn't a scaling issue. Suggesting we can ignore the problem of a bad experience for users on slow networks just because we operate at a smaller scale is plain wrong, and anyone making web tech with that attitude is failing the people who have to use the code they write.
      • kylemh 7y ago
• c-smile 7y ago
  Or just implement React natively so speed will not be an issue: https://sciter.com/sciter-4-4-0-0-with-reactor-on-board/ https://sciter.com/sciter-4-4-0-0-with-reactor-on-board/
• danabramov 7y ago
  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
• anderspitman 7y ago
  Rich Harris' excellent talk Rethinking Reactivity has an interesting section where he compares a React Concurrent Mode demo to Svelte: https://youtu.be/AdNJ3fydeao?t=1128 https://youtu.be/AdNJ3fydeao?t=1128
  • danabramov 7y ago
    This comparison focuses on just one aspect of Concurrent Mode and misses the big picture. I'll believe it when I see these demos ported to Svelte: https://reactjs.org/docs/concurrent-mode-patterns.html https://reactjs.org/docs/concurrent-mode-patterns.html
    • anderspitman 7y ago
      So you're saying Svelte might have the best performance, but Concurrent Mode makes it much easier to achieve medium performance (there certainly would be value in that)? Sorry, haven't had time to read all the material yet.
      • danabramov 7y ago
        I'm saying that I don't see how you're going to implement these "pending loading state" patterns in Svelte but I'd sure like to be proven wrong. It doesn't make sense to try to summarize that page. I've been writing it for two days and it's the shortest that I could compress the essence. I'd be happy to respond to questions you'll have after reading :-)
        • thebosz 7y ago
          You deserve a vacation!
• orangepanda 7y ago
  > It would be nice if we could “skip” it and wait for some content to load before transitioning to the new screen. Yes please! I do hope this pattern catches on. Not only are full page loading screens on every interaction obnoxious, I’m sure they also require an epilepsy warning.
• runawaybottle 7y ago
  I just want to take a moment and say , while Dan is smart and has probably the right patterns we all need to implement, he is a horrific API writer. So none of this could be abstracted right? Like, jesus, not functions but reducers, not straight for ‘cancelRender’ but ‘Suspense’ Api. There was a guy once upon a time that said ‘$(‘.comments’)’, that makes sense , it’s intuitive. These APIs are just getting dumb from a common sense perspective.
  • leerob 7y ago
    Dan didn't write the entire API himself. I'm sure the whole React core team contributed in some fashion and it went through various code reviews. No need to bash.
    • runawaybottle 7y ago
      Well you know not to be too snarky, but some of these framework writers now days would argue ‘bashing has its place, not everyone needs to be bashing’ I’m just showing you that a shitty version of discourse is available if you need it for your use case.
• burgerzzz 7y ago
  React.js is literally the only reason I'm still in software engineering. I know I should learn Scala and be a full stack developer again, but at almost 34, I really feel like I've found my niche in frontend React development. I trusted the React team when they released hooks, and I've never loved coding more than now. Everything just makes sense, and it seems to always work when you follow the best practices. I'm excited to start learning more about Concurrent Mode and Suspense.
• nojvek 7y ago
  This seems quite complicated. Rarely the big perf hit is in js. The big perf hit is usually layout, composite and paint cycles. They are eons slower than manipulating a virtual dom tree in js. So I don’t get it. You can’t interrupt the browsers native paint cycle. Once you say node.appendChild or change some attr/style. The browsers gonna do what the browsers gonna do. React was simple. With hooks , concurrent mode, virtual events and mumbo jumbo. I don’t get it anymore. It’s not a lean mean library that takes minutes to run and one can’t read the source in a couple of hours
  • countryqt30 7y ago
    We switched to vueJS and never regretted :)
  • james_s_tayler 7y ago
    >React was simple. With hooks , concurrent mode, virtual events and mumbo jumbo. I don’t get it anymore. It’s not a lean mean library that takes minutes to run and one can’t read the source in a couple of hours I feel that. One of the top voted questions was "how do I do a simple form submission?" and the response was "it all depends on your state management caching behavior". I think that highlights just how beginner unfriendly some of this stuff has become.
    • latchkey 7y ago
      I ran into that myself while working on a form heavy project. You can use various react form libraries to help make things easier, but then you need to figure out how to wrap your favorite visual component library. Passing all the properties between the two is really really confusing. I'm a fan of the Material-UI project which provides the visual components and ability to style them however you want. React Final Form is terrific with managing forms (and easily made very performant). imho, these form components become really nice to work with... Demo: https://lookfirst.github.io/mui-rff/ https://lookfirst.github.io/mui-rff/ Codesandbox: https://codesandbox.io/s/react-final-form-material-ui-example-tqv09 https://codesandbox.io/s/react-final-form-material-ui-exampl... Code: https://github.com/lookfirst/mui-rff https://github.com/lookfirst/mui-rff
• LuvDoctor08 7y ago
  Wow
  • LuvDoctor08 7y ago
    Beautiful
    • LuvDoctor08 7y ago
      Wonderful
• mrmonkeyman 7y ago
  Just use Angular.
• shadowgovt 7y ago
  I like what I see from Suspense. I've had to implement that pattern myself a couple of times before in Angular; it's common enough to justify a standard approach. EDIT: This is better than what I've implemented. My solutions have involved data-load waterfalls. I'll have to crack the code open and see how Suspense is pulling this approach off; it's pretty cool!