Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scheduling in React

philippspiess.com

Post reply on HN
Print view View original

81–90 of 109 posts

Re: Scheduling in React

#81

Post by philipp-spiess »

gambler wrote: post #79
danabramov wrote: post #64

Earlier quoted context omitted.

The important part btw is that in Concurrent Mode we can interrupt a render in the middle if user does an interaction, and handle that interaction first. Without blocking the thread. This is something setTimeout is incapable of helping with. Because even if you delay the work, at some point it’s still gonna block. In either case this example is very simplified and doesn’t illustrate the subtle difference as much. We’…

>in Concurrent Mode we can interrupt a render in the middle if user does an interaction Can you interrupt an arbitrary user-written function that's called inside the rendering stack?

No, that's not possible in JavaScript. The important part is that React components are lazily evaluated[1] and are not rendered as a stack. So React can render a few components and then pause for higher priority work.

As a user of the framework, you don't need to care about this though. So your mental model can be that of an interruptable function.

[1]: https://overreacted.io/react-as-a-ui-runtime/#lazy-evaluatio...

Re: Scheduling in React

#82

Post by dana321 »

amelius wrote: post #80
dplgk wrote: post #13

I understand the need but this adds serious complexity and wouldn't recommend that this becomes the standard for UX in React. A user is often ok with a delay and it may not worth the tech debt. That said, a very well written article.

> it may not worth the tech debt Management is complaining that our website is less responsive than our competition's ...

Responsive as in ms delay from click to action or responsive as in mobile/tablet visual scaling?

Re: Scheduling in React

#83

Post by aidos »

danabramov wrote: post #55

Dan from React team checking in, just wanted to post a few extra thoughts about this! https://twitter.com/dan_abramov/status/1103768273064259590

This is really interesting work. Looking forward to seeing how this plays out. Someone below mentioned that it won’t play nicely with mobx - can you point to more details about the limitions that we will run into?

Also just wanted to say a quick thank you to the whole React team for the work you’re doing. After some initial scepticism about the necessity of hooks, we’ve been really enjoying the mental model they bring to implementing more interesting behaviours in our components.

Re: Scheduling in React

#84

Post by dana321 »

danabramov wrote: post #65
dplgk wrote: post #13

I understand the need but this adds serious complexity and wouldn't recommend that this becomes the standard for UX in React. A user is often ok with a delay and it may not worth the tech debt. That said, a very well written article.

Most of the complexity is inside of React, not in the app. Your components look pretty much the same — except that you have more control over scheduling when you need to .

React trades simplicity of certain things such as dom manipulation, and makes it difficult to fetch external (ie noncompiled) html and include it as react dom nodes, and ad serving is pretty difficult too because most ads use document.write and this paradigm doesn't work with react, as well as single page applications and the rendering of contextual advertising requires server-side rendering too.

State management solutions like redux; nobody i know or have seen does it exactly the same, its really tricky to use and takes a long time to get the hang of.

Re: Scheduling in React

#85

Post by dana321 »

quickthrower2 wrote: post #40
sktrdie wrote: post #23

I feel that this low-level performance stuff should exist in browser-land and not in framework-land. Kudos to React for finding a good implementation though

We’ll end up with threads in JS one day.

I would prefer that they implement it in the same way go has with channels.

Re: Scheduling in React

#86

Post by exogen »

gambler wrote: post #48

You can significantly improve on the baseline performance simply by doing: handleChange = event => { const value = event.target.value; this.setState({ inputValue: value }); setTimeout(() => { this.props.onChange(value); }, 1); setTimeout(() => { sendAnalyticsPing(value); }, 1); }; And wrapping mining function inside Name(): setTimeout(() => { miningBitcoin(2); }, 1); In fact, to me this pretty much seems as fast as t…

In addition to everyone else's comments, there's another big problem: browsers treat setTimeout delays as very loose suggestions.

If you're scrolling when one of these timeouts is set, or one starts and then you start scrolling, it's possible for the browser to delay the callback for a super noticeable amount of time, on the order of 3–10 seconds (about a thousand times slower than you intended).

Re: Scheduling in React

#87

Post by zemptime »

throwaway66666 wrote: post #38

We used this technique in the IE6 days (with settimeout nonetheless). We had a very big list that was being filtered as the user typed, and we would perform 10 dom operations (they were all creating and appending elements to the dom), then timeout for 15ms, then 10 more operations, etc. If the user changed the text, we would clear the most recent timeout which would stop the chain, it was very clean actually. I suppo…

It's already popping up again in some other places! (For what I assume will be until browsers get an actual scheduling api)

https://www.youtube.com/watch?v=ypPRdtjGooc

Re: Scheduling in React

#88

Post by hombre_fatal »

Tade0 wrote: post #60
hombre_fatal wrote: post #46

Earlier quoted context omitted.

People are highly aware of when their input is locked up. It's like trying to type commands over SSH on a bad or laggy connection: you have to keep pausing, wait for it to catch up, and ensure there are no typos or anything. Oops, need to backspace, wait, and edit that character. Oops, backed up too far. Classic example of this is a naive markdown preview box that updates on every keypress. As the input grows, the ex…

Though I found the demonstration intolerable and would hope, as a user of your application, that you wouldn't settle on "meh, the user won't notice/care." Actually I would just debounce it and add a spinner. No need to shoehorn additional operations in between, which are going be outdated in a split second anyway.

Debouncing just means the UI lock happens slightly less often. Not sure how a spinner is going to work when we're talking about synchronous updates which the article's `mineBitcoin()` is trying to simulate.

So it just depends on how much you care about UX. And consider my markdown preview example where UI lock on every Nth keypress is hardly better than every keypress.

If you don't care, then why bother with auto-updating on keypress at all? Just wait for user to press enter. Much less jarring for the user than a shoddy half-solution.

Re: Scheduling in React

#89

Post by vvanders »

throwaway66666 wrote: post #45
acemarke wrote: post #39

Earlier quoted context omitted.

Oh, it goes back quite a bit further than that :) https://blog.codinghorror.com/is-doevents-evil/

Hah, of course, spoke too soon! And it's by Jeff Atwood! I got the idea back then from some game devs who used a variation of this technique (though theirs was a queue mechanism for prioritizing disk reads to speed up loading of important assets and defer the rest in the old magnetic days). Anyway, congrats to the react team, really cool. I am wondering if they plan to abstract it completely so that everyone uses it…

A lot of gamedev networking is like this too. Half making sure your game model works in a latent environment/can be extrapolated. The other half is clever tricks(particle systems! sound effects!) to make the player think something is happening when you're just waiting to reconverge the state with an authorative response from the server.

Re: Scheduling in React

#90

Post by BigJono »

bfrydl wrote: post #75
acemarke wrote: post #63

Earlier quoted context omitted.

FWIW, I'm a Redux maintainer, and I built this specifically in response to how I've seen people _want_ to use Redux, and the concerns they've raised about using Redux. [0] Almost everyone uses `redux-thunk` [1]. Adding that to a plain Redux store takes a few steps. Adding middleware _and_ setting up the Redux DevTools Extension adds another couple steps [2] So, RSK's `configureStore()` does that by default [3]. Accid…

That was a very defensive response. Look it's excellent for you that many people want to use your work and think it looks awesome. I am just not one of those people, for reasons developed over years of using Redux professionally. It seems like you think I am just missing something, and that's why I don't agree with you. You should really be more open to the idea that others might think very differently from you and t…

I've been down this path with acemarke before, about redux-thunk even. All of his commits on Redux are documentation changes, and he feels the need to spam every React thread on this site with comments that start with "I'm a Redux maintainer". In-fact if you google "Redux maintainer" this guy's posts are the first thing that shows up.

Also, when React 16 came out with the new Context API, acemarke made a terrible blog post called "Is Redux Dead?", which had links to some sort of paid Redux training, and linked it everywhere without disclosing that fact. He regularly links said posts from his blog (which I assume have the same links to paid training) under the guise of helping beginners, and I'm really not sold that they actually accomplish that at all. In-fact quite the opposite.

It all seems pretty shifty and dishonest.

Post reply on HN