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

91–100 of 109 posts

Re: Scheduling in React

#91

Post by taeric »

onion2k wrote: post #53
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.

A user is often ok with a delay... Every user group focus test I've ever done on an app with a janky UI has brought it up as a significant "The app is so slow!" issue. On the things I build users hate UI delays.

This is a tough one. If asked, most everyone will complain about delays. Just like, if asked, most people will complain about the color choice. Doesn't mean it is the best place to focus on at first.

In areas where the latency has been solved, don't make the options worse for the user. There are bare minimums, but they are usually hard to mess up. Such that, if you are bringing something new to the table, focus on that first.

Re: Scheduling in React

#92

Post by acemarke »

BigJono wrote: post #90
bfrydl wrote: post #75

Earlier quoted context omitted.

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 blo…

> All of his commits on Redux are documentation changes

ahem

https://github.com/reduxjs/react-redux/pull/1000/commits/c9d...

https://github.com/reduxjs/react-redux/pull/1065

https://github.com/reduxjs/react-redux/issues/1177

https://github.com/reduxjs/react-redux/commits/connect-subsc...

Re: Scheduling in React

#94

Post by ivanwonder »

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?

I think to interrupt a render means interrupt the process of reconciliation. you don't have to response the user input until the difference of whole React element has been found. https://overreacted.io/react-as-a-ui-runtime/#consistency

Re: Scheduling in React

#95

Post by Tade0 »

hombre_fatal wrote: post #88
Tade0 wrote: post #60

Earlier quoted context omitted.

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-upd…

Debouncing just means the UI lock happens slightly less often.

No, it means it happens only after the user stopped typing for a while - a very different experience.

If you don't care, then why bother with auto-updating on keypress at all? Just wait for user to press enter.

Doesn't cover all the cases and you have to update eventually - after the first debounced event goes through is a good moment.

Re: Scheduling in React

#96

Post by kalmi10 »

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.

Relevant: https://developers.google.com/web/updates/2018/10/wasm-threa...

Re: Scheduling in React

#97

Post by symboltoproc »

dana321 wrote: post #84
danabramov wrote: post #65

Earlier quoted context omitted.

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 sol…

I have always considered React one of the frameworks that allows you to interop with regular HTML and JavaScript the easiest. The reason being that you can easily access DOM nodes and everything is run in JavaScript anyway. This is a lot more complicated in languages where you have a template language in my own experience.

That said, document.write is kind of special since it requires JavaScript to run while the HTML document is still open (so before it fires the loaded event). There is a reason this API is barely used today and mostly superset by appendChild.

Re: Scheduling in React

#98

Post by reacweb »

nkg wrote: post #67

As users, don't you get mad when you type "mustang" in an input and it displays "msutgna" because of some badly handled onChange event? We are overriding so much of the browser's default behavior that we need to reimplement its basic features.

I have already encounter this behaviour, but I do not understand it. What is the mistake to avoid ?

Re: Scheduling in React

#99

Post by philipp-spiess »

Tade0 wrote: post #95
hombre_fatal wrote: post #88

Earlier quoted context omitted.

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-upd…

Debouncing just means the UI lock happens slightly less often. No, it means it happens only after the user stopped typing for a while - a very different experience. If you don't care, then why bother with auto-updating on keypress at all? Just wait for user to press enter. Doesn't cover all the cases and you have to update eventually - after the first debounced event goes through is a good moment.

The batching effect of a debounced input is very important. Running an update for every keystroke is expensive and you only want to run it with the latest input anyway. This is why Concurrent React will make batching the default behavior.

Internally, React manages a list of updates. Whenever you trigger one, it will be added to the list but the next re-render will only start after the previous one has finished (this is of course a simplified explanation but you get the idea).

This batching gives us the best of both worlds: We start rendering as soon as we have data and don’t have “idle” time in which the UI is unresponsive (like a long debounce function) but we still batch all updates between the different renderings so that we can skip individual updates to save time.

Re: Scheduling in React

#100

Post by ex3ndr »

nkg wrote: post #67

As users, don't you get mad when you type "mustang" in an input and it displays "msutgna" because of some badly handled onChange event? We are overriding so much of the browser's default behavior that we need to reimplement its basic features.

That probably not just input, but content editable. Unfortunately this feature is really very hard to support well and there are still bugs in all editors.
Post reply on HN